idnits 2.17.1 draft-ietf-dnsind-rollover-00.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: ---------------------------------------------------------------------------- ** 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? == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 10 longer pages, the longest (page 2) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 11 pages 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. ** There are 10 instances of too long lines in the document, the longest one being 2 characters in excess of 72. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The "Author's Address" (or "Authors' Addresses") section title is misspelled. == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 (October 1999) is 8960 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) -- Looks like a reference, but probably isn't: '1035' on line 68 == Unused Reference: 'RFC 1035' is defined on line 374, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2535 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) ** Obsolete normative reference: RFC 2541 (Obsoleted by RFC 4641) Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT DNSIND Key Rollover 2 Expires October 1999 3 draft-ietf-dnsind-rollover-00.txt 5 Domain Name System (DNS) Security Key Rollover 6 ------ ---- ------ ----- -------- --- -------- 8 Donald E. Eastlake 3rd, Mark Andrews 10 Status of This Document 12 This draft, file name draft-ietf-dnsind-rollover-00.txt, is intended 13 to be become a Proposed Standard RFC. Distribution of this document 14 is unlimited. Comments should be sent to the DNS working group 15 mailing list or to the authors. 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 24 months. Internet-Drafts may be updated, replaced, or obsoleted by 25 other documents at any time. It is not appropriate to use Internet- 26 Drafts as reference material or to cite them other than as a 27 ``working draft'' or ``work in progress.'' 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 Deployment of Domain Name System (DNS) security with good cryptologic 38 practice will involve large volumes of key rollover traffic. A 39 standard format and protocol for such messages will be necessary for 40 this to be practical and is specified herein. 42 [Note: this draft has been moved to dnsind from dnssec as part of the 43 ongoing combination of these working groups. It would have been 44 draft-ietf-dnssec-rollover-01.txt otherwise.] 46 Table of Contents 48 Status of This Document....................................1 49 Abstract...................................................1 51 Table of Contents..........................................2 53 1. Introduction............................................3 54 2. Key Rollover Scenario...................................3 55 3. Rollover Operation......................................5 56 3.1 Rollover to Parent.....................................5 57 3.2 Rollover to Children...................................6 58 4. Secure Zone Cuts and Joinders...........................7 59 5. Security Considerations.................................8 60 6. IANA Considerations.....................................9 62 References................................................10 63 Authors Address...........................................10 64 Expiration and File Name..................................11 66 1. Introduction 68 The Domain Name System (DNS) [RFC 1034, 1035] is the global 69 hierarchical replicated distributed database system for Internet 70 addressing, mail proxy, and other information. The DNS has been 71 extended to include digital signatures and cryptographic keys as 72 described in [RFC 2535]. 74 The principle security service provided for DNS data is data origin 75 authentication. The owner of each zone signs the data in that zone 76 with a private key known only to the zone owner. Anyone that knows 77 the corresponding public key can then authenticate that zone data is 78 from the zone owner. To avoid having to preconfigure resolvers with 79 all zone's public keys, keys are stored in the DNS with each zone's 80 key signed by its parent (if the parent is secure). 82 To obtain high levels of security, keys must be periodically changed, 83 or "rolled over". The longer a private key is used, the more likely 84 it is to be compromised due to cryptanalysis, accident, or treachery 85 [RFC 2541]. 87 In a widely deployed DNS security system, the volume of update 88 traffic will be large. Just consider the .com zone. If only 10% of 89 its children are secure and change their keys only once a year, you 90 are talking about hundreds of thousands of new child public keys that 91 must be securely sent to the .com manager to sign and return with 92 their new parent signature. And when .com rolls over its private 93 key, it will needs to send hundred of thousands of new signatures on 94 the existing child public keys to the child zones. 96 It will be impractical to handle such update volumes manually on a 97 case by case basis. The bulk of such key rollover updates must be 98 automated. 100 The key words "MUST", "REQUIRED", "SHOULD", "RECOMMENDED", and "MAY" 101 in this document are to be interpreted as described in [RFC 2119]. 103 2. Key Rollover Scenario 105 Although DNSSEC provides for the storage of other keys in the DNS for 106 other purposes, DNSSEC zone keys are included solely for the purpose 107 of being retrieved to authenticate DNSSEC signatures. Thus, when a 108 zone key is being rolled over, the old public key should be left in 109 the zone, along with the addition of the new public key, for as long 110 as it will reasonably be needed to authenticate old signatures that 111 have been cached or are held by applications. Similarly, old parent 112 SIGs should be retained for a short time after a parent KEY(s) roll 113 over and new parent SIGs have been installed. 115 If DNSSEC were universally deployed and all DNS server's clocks were 116 synchronized and zone transfers were instantaneous etc., it might be 117 possible to avoid ever having duplicate old/new KEY/SIG RRsets due to 118 simultaneous expiration of SIGs everywhere in the DNS. But these 119 assumptions do not hold. Security aware DNS servers decrease the TTL 120 of secure RRs served as the expiration of their authenticating SIG(s) 121 approaches but some dithered fudge must generally be left due to 122 clock skew, RR retention by applications, and the like. Retaining 123 old KEYs for a while after rolling over to new KEYs will be necessary 124 in practical cases. 126 Assume a middle zone with a secure parent and a secure child wishes 127 to role over its KEY RRset. This RRset would probably be one KEY RR 128 per crypto algorithm used to secure the zone, but for this scenario, 129 we will simply assume it is one KEY RR. The old KEY RR and two SIG 130 RRs will exist at the apex of the middle zone. (These RRs may also 131 exist at the leaf node for this zone in its parent if the parent 132 chooses to store them there.) The contents of the middle zone and the 133 zone KEY RRs of its secure child will have SIGs under the old key. 135 The middle zone owner needs to communicate with its parent to obtain 136 a new parental signature covering both the old and new KEY RRs and 137 covering just the new KEY RR. The signature on both is needed so the 138 old KEY can be retain for the period it might be needed to 139 authenticate old SIGs. The middle zone would probably want to obtain 140 these in advance so that it can install them at the right time along 141 with its new SIG RRs covering the content of its zone. Finally, it 142 needs to give new SIG RRs to its child that cover its KEY RRs so it 143 must signal its children to ask for such SIG RRs. 145 BEFORE ROLLOVER SHORTLY AFTER AFTER ROLLOVER 147 p.x KEY P1 p.x KEY P1 p.x KEY P1 148 p.x SIG(KEY) P1 p.x SIG(KEY) P1 p.x SIG(KEY) P1 149 p.x SIG(KEY) GP p.x SIG(KEY) GP p.x SIG(KEY) GP 151 m.p.x KEY M1 m.p.x KEY M2 m.p.x KEY M2 152 m.p.x SIG(KEY) P1 m.p.x KEY M1 m.p.x SIG(KEY) P1 153 m.p.x SIG(KEY) M1 m.p.x SIG(KEY) P1 m.p.x SIG(KEY) M2 154 m.p.x SIG(KEY) M2 156 c.m.p.x KEY C1 c.m.p.x KEY C1 c.m.p.x KEY C1 157 c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) M2 c.m.p.x SIG(KEY) M2 158 c.m.p.x SIG(KEY) C1 c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) C1 159 c.m.p.x SIG(KEY) C1 161 p = parent, m = middle, c = child, GP = grandparent key 162 P* = parent key, M* = middle zone key, C* = child key 164 3. Rollover Operation 166 Rollover operations use a DNS request syntactically identical to the 167 UPDATE request [RFC 2136] (except that the operation code is ROLLOVER 168 which is equal to (TBD)) and use a new form of NOTIFY [RFC 1996]. 169 Considerations for such requests to the parent and children of a zone 170 are givens below. 172 All rollover operations involve significant amounts of cryptographic 173 calculations. Appropriate rate limiting SHOULD be applied to avoid 174 denial of service attacks. 176 [This draft does not consider cross-certification key rollover.] 178 3.1 Rollover to Parent 180 A zone rolling over its KEY RRset sends an upward ROLLOVER request to 181 its parent. Actually, it will normally do two upward ROLLOVERs, one 182 for a combined KEY RRset of its old and new KEYs and one for just its 183 new KEY RRset, as discussed above. 185 The server selection algorithm in [RFC 2136] section 4 should be 186 used. A child needs to be configured with or determine the name of 187 its parent but SHOULD NOT remember the location of its parent other 188 than via normal DNS caching of address RRs so that rollover will 189 continue to work if its parent servers are moved. 191 The ROLLOVER request Zone should be specified as the parent zone. 192 The request Update section has the new KEY RRset on which the parent 193 signature is requested along with the requesting zone's SIG(s) under 194 its old KEY(s) as RRs to be "added" to the parent zone. The 195 inception and expiration times in this child SIG or SIGs are the 196 requested inception and expiration times for the new parent SIG(s). 197 The "prerequisites" section has the old child KEY RRset with the 198 parent SIG (see next paragraph). 200 An upward ROLLOVER request MUST be signed and if not signed a BADAUTH 201 response generated. The signature MUST be under the previous zone 202 KEY, so the parent can validate it, or under a valid TSIG key 203 [draft-ietf-dnsind-tsig-*.txt] arranged with the parent. Including 204 the "prerequisite" section as specified above enables a parent that 205 keeps no record of its children's KEYs to still authenticate a 206 child's ROLLOVER request based on the old child KEY because the 207 parent is presented with its own SIG on the old KEY. 209 If the ROLLOVER command is erroneous or violates parental policy, an 210 Error response is returned. If a parent retains copies of its 211 children's KEYs, it may use that knowledge to validate ROLLOVER 212 request SIGs and ignore the "prerequisites" section. 214 If the ROLLOVER command is OK and the parent can sign online, its 215 response MAY include the new parent SIG(s) in the response Update 216 section. This response MUST be sent to the originator of the 217 request. 219 If the parent can not sign online, it should return a response with 220 an empty Update section and queue the SIG(s) calculation request. 221 This response MUST be sent to the originator of the request. 223 ROLLOVER response messages MUST always include the actual parent's 224 SOA signed with a key the child should recognize in the Additional 225 Information section (see section 4 below). 227 Regardless of whether the server has sent the new signatures above, 228 it MUST, once it has calculated the new SIG(s), send a ROLLOVER to 229 the child zone using the DNS port (53) and the server selection 230 algorithm defined in RFC 2136, Section 4. This ROLLOVER reqeust 231 contains the KEY RRset that triggered it and the new SIG(s). There 232 are several reasons for sending the ROLLOVER response regardless of 233 whether the new SIG RR(s) were sent in the original response. One is 234 to provide an indication to the operators of the zone in the event 235 someone is trying to hijack the zone. Another is that this maximizes 236 the probability of the response getting through. 238 Although the parent zone need not hold or serve the child's key, if 239 it does the ROLLOVER command REQUEST SHOULD NOT automatically update 240 the parent zone. A later UPDATE command can be used to actually put 241 the new KEY into the parent zone if desired and supported by parent 242 policy. 244 This document does not cover the question of parental policy on key 245 rollovers. Parents may have restrictions on how far into the future 246 they will sign KEY RRsets, what algorithms or key lengths they will 247 support, might require payment for the service, etc. The signing of 248 a future KEY by a parent is, to some extent, a granting of future 249 authoritative existence to the controller of the child private key 250 even if the child zone ownership should change. The only effective 251 way of invalidating such future signed child public keys would be for 252 the parent to roll over its key(s), which might be an expensive 253 operation. 255 3.2 Rollover to Children 257 When a secure zone is going to rollover its key(s), it needs to re- 258 sign the zone keys of any secure children under its new key(s). The 259 parent simply notifIES the child via a rollover NOTIFY [RFC 1996] 260 that the parent KEY(s) have changed. The child then proceeds to do 261 an upward ROLLOVER request, as described in 3.1 above to obtain the 262 new parental SIG(s). 264 A rollover NOTIFY is a NOTIFY request [RFC 1996] that has a QTYPE of 265 SIG and the owner name of the child zone. The answer section has the 266 current parent SOA signed by a key the child will know (see section 267 4). 269 A rollover NOTIFY MUST be signed and if not signed a BADAUTH response 270 generated. The signature MUST be under the previous parental zone 271 KEY, so the child can validate it, or under a valid TSIG key [draft- 272 ietf-dnsind-tsig-*.txt] negotiated between parent and child. 274 The rollover NOTIFY can be sent to any of the nameservers for the 275 child using the nameserver selection algorithm defined in RFC 2136, 276 Section 4. Nameservers for the child zone receiving a rollover 277 NOTIFY query will forward the rollover NOTIFY in the same manner as 278 an UPDATE is forwarded. 280 Unless the master server is configured to initiate an automatic 281 ROLLOVER it MUST seek to inform its operators that a rollover NOTIFY 282 request has been received. This could be done by a number of methods 283 including generating a log message, generating an email request to 284 the child zone's SOA RNAME or any other method defined in the 285 server's configuration for the zone. The default SHOULD be to send 286 mail to the zone's SOA RNAME. As with all rollover operations, care 287 should be taken to rate limit these messages so prevent them being 288 used to facilitate a denial of service attack. 290 Once the message has been sent (or suppressed if so configured) to 291 the child zone's administrator the master server for the child zone 292 is free to respond to the rollover NOTIFY request. 294 4. Secure Zone Cuts and Joinders 296 There are two other events that have some similarity to key rollover. 298 The first is when a secure zone the is more than one level deep has a 299 zone cut introduced inside it. For example, assume zone example.com 300 has a.b.c.example.com, d.b.c.example.com and e.example.com in it. A 301 zone cut could be introduced such that b.c.example.com became a 302 separate child zone of example.com. A real world exampe would be a 303 company that structures its DNS as host.branch.company.example. It 304 might start out will all of these names in one zone but later decide 305 to delegate all or some of the branches to branch zone file 306 maintainers. 308 The second is when a secure zone absorbs a child zone eliminating a 309 zone cut. This is simply the inverse of the previous paragraph. 311 From the point of view of the parent zone above the splitting zone or 312 above the upper of the two combining zones, there is no change. 314 When a zone is split by introducing a cut, the newly created child 315 must be properly configured. 317 However, from the point of view of a child of the splitting zone 318 which becomes a grandchild or a grandchild that becomes a child due 319 to joinder, there is a change in parent name. Therefore, in general, 320 there is a change in parent KEY(s). Unless the entity that handles 321 rollovers for the zone whose parent name has changed is appropriately 322 updated, future automated rollover will fail because it will be sent 323 to the old parent. 325 For this reason and so that other consistency checks can be made, the 326 parent SOA and SIG(SOA) are always included in the Answer section of 327 rollover NOTIFY requests and in ROLLOVER responsess. For automated 328 rollover to the new cut or joined state to work, these SOAs must be 329 signed with old KEY(s) of the former parent so the signatures can be 330 validated by the zone whose parent name is changing. In the case of 331 a joinder, if the private key of the pinched out middle zone is not 332 available, then manual update of the former grandchild, now child, 333 will be necessary. In the case of introducing a cut, operational 334 coordination with the former parent, now grandparent, signing the 335 initial updates to the former child, now grandchild, will be needed 336 to automate the reconfiguration of the zones. 338 5. Security Considerations 340 The security of ROLLOVER or UPDATE requests is essential, otherwise 341 false children could steal parental authorization or a false parent 342 could cause a child to install an invalid signature on its zone key, 343 etc. 345 A ROLLOVER request can be authenticated by request SIG(s)under the 346 old zone KEY(s) of the requestor [RFC 2535]. The response SHOULD 347 have transaction SIG(s) under the old zone KEY(s) of the responder. 348 (This public key security could be used to rollover a zone to the 349 unsecured state but at that point it would generally not be possible 350 to roll back without manual intervention.) 352 Alternatively, if there is a prior arrangement between a child and a 353 parent, ROLLOVER requests and responses can be secured and 354 authenticated using TSIG [draft-ietf-dnsind-tsig-*.txt]. (TSIG 355 security could be used to rollover a zone to unsecured and to 356 rollover an unsecured zone to the secured state.) 358 A server that implements online signing SHOULD have the ability to 359 black list a zone and force manual processing or demand that a 360 particular signature be used to generate the ROLLOVER request. This 361 it to allow ROLLOVER to be used even after a private key has been 362 compromised. 364 6. IANA Considerations 366 The DNS operation code (TBD) is assigned to ROLLOVER. There are no 367 other IANA considerations in this document. 369 References 371 [RFC 1034] - "Domain names - concepts and facilities", P. 372 Mockapetris, 11/01/1987. 374 [RFC 1035] - "Domain names - implementation and specification", P. 375 Mockapetris, 11/01/1987. 377 [RFC 1996] - "A Mechanism for Prompt Notification of Zone Changes 378 (DNS NOTIFY)", P. Vixie, August 1996. 380 [RFC 2119] - "Key words for use in RFCs to Indicate Requirement 381 Levels", S. Bradner. March 1997. 383 [RFC 2136] - "Dynamic Updates in the Domain Name System (DNS 384 UPDATE)", P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 385 1997. 387 [draft-ietf-dnsind-tsig-*.txt] 389 [RFC 2535] - "Domain Name System Security Extensions", D. Eastlake. 390 March 1999. 392 [RFC 2541] - "DNS Security Operational Considerations", D. Eastlake. 393 March 1999. 395 Authors Address 397 Donald E. Eastlake 3rd 398 IBM 399 65 Sindegan Hill Road, RR #1 400 Carmel, NY 10512 402 Telephone: +1 914-276-2668 (h) 403 +1 914-784-7913 (w) 404 FAX: +1 914-784-3833 (w) 405 EMail: dee3@us.ibm.com 407 Mark Andrews 408 Internet Software Consortium 409 1 Seymour Street 410 Dundas Valley, NSW 2117 411 AUSTRALIA 413 Telephone: +61-2-9871-4742 414 Email: marka@isc.org 416 Expiration and File Name 418 This draft expires in October 1999. 420 Its file name is draft-ietf-dnsind-rollover-00.txt.