idnits 2.17.1 draft-ietf-dnsop-rollover-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. ** There are 10 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (June 2001) is 8344 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 379, 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) ** Obsolete normative reference: RFC 2845 (Obsoleted by RFC 8945) Summary: 8 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT DNSSEC Key Rollover 2 UPDATES RFC 1996 December 2000 3 Expires June 2001 5 Domain Name System (DNS) Security Key Rollover 6 ------ ---- ------ ----- -------- --- -------- 7 9 Mark Andrews, Donald E. Eastlake 3rd 11 Status of This Document 13 This draft is intended to be become a Proposed Standard RFC. 14 Distribution of this document is unlimited. Comments should be sent 15 to the Domain Name Server Operations working group mailing list 16 or to the authors. 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC 2026. Internet-Drafts are 20 working documents of the Internet Engineering Task Force (IETF), its 21 areas, and its working groups. Note that other groups may also 22 distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "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 traffic will be necessary for 40 this to be practical and is specified herein. 42 [Note: The previous versions of this draft included draft-ietf- 43 dnsind-rollover-*.txt and draft-ietf-dnssec-rollover-*.txt.] 45 Table of Contents 47 Status of This Document....................................1 48 Abstract...................................................1 50 Table of Contents..........................................2 52 1. Introduction............................................3 53 2. Key Rollover Scenario...................................3 54 3. Rollover Operation......................................5 55 3.1 Rollover to Parent.....................................5 56 3.2 Rollover to Children...................................7 57 4. Secure Zone Cuts and Joinders...........................8 58 5. Security Considerations.................................9 59 6. IANA Considerations.....................................9 61 References................................................10 63 Authors Address...........................................11 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 a few 89 percent of its children are secure and change their keys only once a 90 year, you are talking about hundreds of thousands of new child public 91 keys that must be securely sent to the .com manager to sign and 92 return with their new parent signature. And when .com rolls over its 93 private key, it will need to send hundred of thousands of new 94 signatures on 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, rounding, RR retention by applications, and the like. 123 Retaining old KEYs for a while after rolling over to new KEYs will be 124 necessary in practical cases. 126 Assume a secure middle zone with a secure parent and a secure child 127 wishes to role over its KEY RRset. This RRset would probably be one 128 KEY RR per crypto algorithm used to sign the zone, but for this 129 scenario, we will simply assume it is one KEY RR. The old KEY RR and 130 two SIG RRs, one signed by the parent and one signed by the zone 131 itself, will exist at the apex of the middle zone. (These RRs may 132 also exist at the leaf node for this zone in its parent if the parent 133 chooses to store them there.) The contents of this middle zone and 134 the zone KEY RRs of its secure child will have SIGs under the old 135 key. 137 The middle zone owner needs to communicate with its parent to obtain 138 a new parental signature covering both the old and new KEY RRs and a 139 parental signature covering just the new KEY RR. The signature on 140 both is needed so the old KEY can be retain for the period it might 141 be needed to authenticate old SIGs. The middle zone would probably 142 want to obtain these in advance so that it can install them at the 143 right time along with its new SIG RRs covering the content of its 144 zone. Finally, it needs to give new SIG RRs to its child that cover 145 the child's KEY RRs so it must signal its children to ask for such 146 SIG RRs. 148 The table below illustrates what happens during this rollover 149 scenario: 151 BEFORE ROLLOVER SHORTLY AFTER AFTER ROLLOVER 153 p.x KEY P1 p.x KEY P1 p.x KEY P1 154 p.x SIG(KEY) P1 p.x SIG(KEY) P1 p.x SIG(KEY) P1 155 p.x SIG(KEY) GP p.x SIG(KEY) GP p.x SIG(KEY) GP 157 m.p.x KEY M1 m.p.x KEY M2 m.p.x KEY M2 158 m.p.x SIG(KEY) P1 m.p.x KEY M1 m.p.x SIG(KEY) P1 159 m.p.x SIG(KEY) M1 m.p.x SIG(KEY) P1 m.p.x SIG(KEY) M2 160 m.p.x SIG(KEY) M2 162 c.m.p.x KEY C1 c.m.p.x KEY C1 c.m.p.x KEY C1 163 c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) M2 c.m.p.x SIG(KEY) M2 164 c.m.p.x SIG(KEY) C1 c.m.p.x SIG(KEY) M1 c.m.p.x SIG(KEY) C1 165 c.m.p.x SIG(KEY) C1 167 p = parent, m = middle, c = child, GP = grandparent key 168 P* = parent key, M* = middle zone key, C* = child key 170 3. Rollover Operation 172 Rollover operations use a DNS request syntactically identical to the 173 UPDATE request [RFC 2136] except that the operation code is ROLLOVER, 174 which is equal to (TBD), and use a new variation of NOTIFY [RFC 175 1996]. Considerations are given below. 177 All rollover operations involve significant amounts of cryptographic 178 calculations. Appropriate rate limiting SHOULD be applied to avoid 179 denial of service attacks. 181 [This draft does not consider cross-certification key rollover.] 183 3.1 Rollover to Parent 185 A zone rolling over its KEY RRset sends an upward ROLLOVER request to 186 its parent. Actually, it will normally do two upward ROLLOVERs, one 187 for a combined KEY RRset of its old and new KEYs and one for just its 188 new KEY RRset, as discussed above. 190 The server selection algorithm in [RFC 2136] section 4 should be used 191 for the retrieval of SRV RRs [RFC 2782] using the service name (tbd) 192 to determine which host(s) to which the ROLLOVER request is sent. A 193 child needs to be configured with or determine the name of its 194 parent. 196 The ROLLOVER request Zone should be specified in the Zone section. 198 The request Update section has the new KEY RRset on which the parent 199 signature is requested along with the requesting zone's SIG(s) under 200 its old KEY(s) as RRs to be "added" to the parent zone. The 201 inception and expiration times in this child SIG or SIGs are the 202 requested inception and expiration times for the new parent SIG(s). 203 The "prerequisites" section has the old child KEY RRset with the 204 parent SIG (see next paragraph). 206 An upward ROLLOVER request MUST be signed and if not signed a BADAUTH 207 response generated. The signature MUST be a SIG(0) using the 208 previous zone KEY, so the parent can validate it, or be under a valid 209 TSIG key [RFC 2845] arranged with the parent. Including the 210 "prerequisite" section as specified above enables a parent that keeps 211 no record of its children's KEYs to still authenticate a child's 212 ROLLOVER request based on the old child KEY because the parent is 213 presented with its own SIG on the old KEY. 215 If the ROLLOVER command is erroneous or violates parental policy, an 216 Error response is returned. If a parent retains copies of its 217 children's KEYs, it MAY use that knowledge to validate ROLLOVER 218 request SIGs and ignore the "prerequisites" section. 220 If the ROLLOVER command is OK and the parent can sign online, its 221 response MAY include the new parent SIG(s) in the response Update 222 section. This response MUST be sent to the originator of the 223 request. 225 If the parent can not sign online in a reasonable length of time, it 226 should return a response with an empty Update section and queue the 227 SIG(s) calculation request. This response MUST be sent to the 228 originator of the request. 230 ROLLOVER response messages MUST always include, in the Additional 231 Information section, the actual parent's SOA signed with a key the 232 child should recognize (see section 4 below). 234 Regardless of whether the server has sent the new signatures above, 235 it MUST, once it has calculated the new SIG(s), send a ROLLOVER to 236 the child zone using the DNS port (53) and host determined as 237 follows: the server selection algorithm defined in RFC 2136, Section 238 4, for updates to the child zone is used to fetch SRV RRs for service 239 name (tbd). This ROLLOVER reqeust contains the KEY RR set that 240 triggered it and the new SIG(s). There are several reasons for 241 sending the ROLLOVER response regardless of whether the new SIG RR(s) 242 were sent in the original response. One is to provide an indication 243 to the operators of the zone in the event someone is trying to hijack 244 the zone. Another is that this maximizes the probability of the 245 response getting through. 247 Although the parent zone need not hold or serve the child's key, if 248 it does, the ROLLOVER command request MAY automatically update the 249 parent zone. 251 This document does not cover the question of parental policy on key 252 rollovers. Parents may have restrictions on how far into the future 253 they will sign KEY RRsets, what algorithms or key lengths they will 254 support, may require payment for the service, etc. The signing of a 255 future KEY by a parent is, to some extent, a granting of future 256 authoritative existence to the controller of the child private key 257 even if the child zone ownership should change. The only effective 258 way of invalidating such future signed child public keys would be for 259 the parent to roll over its key(s), which might be a very expensive 260 operation. 262 3.2 Rollover to Children 264 When a secure zone is going to rollover its key(s), it needs to re- 265 sign the zone keys of any secure children under its new key(s). The 266 parent simply NOTIFies the children via a rollover NOTIFY [RFC 1996] 267 that the parent KEY(s) have changed. The child then proceeds to do 268 an upward ROLLOVER request, as described in 3.1 above to obtain the 269 new parental SIG(s). 271 A rollover NOTIFY is a NOTIFY request [RFC 1996] that has a QTYPE of 272 SIG and the owner name of the child zone. The answer section has the 273 current parent SOA signed by a key the child will know (see section 274 4). 276 A rollover NOTIFY MUST be signed and if not signed a BADAUTH response 277 generated. The signature MUST be under the previous parental zone 278 KEY, so the child can validate it, or under a valid TSIG key [RFC 279 2845] negotiated between parent and child. 281 The rollover NOTIFY MUST be send by using the the nameserver 282 selection algorithm defined in RFC 2136, Section 4, to fetch SRV RRs 283 for the (tbd) named service. Servers for the child zone receiving a 284 rollover NOTIFY query will forward the rollover NOTIFY in the same 285 manner as an UPDATE is forwarded except that they will forward using 286 SRV RRs as above. 288 Unless the rollover server for the zone master is configured to 289 initiate an automatic ROLLOVER it MUST seek to inform its operators 290 that a rollover NOTIFY request has been received. This could be done 291 by a number of methods including generating a log message, generating 292 an email request to the child zone's SOA RNAME or any other method 293 defined in the server's configuration for the zone. The default 294 SHOULD be to send mail to the zone's SOA RNAME. As with all rollover 295 operations, care should be taken to rate limit these messages so 296 prevent them being used to facilitate a denial of service attack. 298 Once the message has been sent (or suppressed if so configured) to 299 the child zone's administrator the master server for the child zone 300 is free to respond to the rollover NOTIFY request. 302 4. Secure Zone Cuts and Joinders 304 There are two other events that have some similarity to key rollover. 306 The first is when a secure zone the is more than one level deep has a 307 zone cut introduced inside it. For example, assume zone example.com 308 has a.b.c.example.com, d.b.c.example.com and e.example.com in it. A 309 zone cut could be introduced such that b.c.example.com became a 310 separate child zone of example.com. A real world example would be a 311 company that structures its DNS as host.branch.company.example. It 312 might start out will all of these names in one zone but later decide 313 to delegate all or some of the branches to branch zone file 314 maintainers. 316 The second is when a secure zone absorbs a child zone eliminating a 317 zone cut. This is simply the inverse of the previous paragraph. 319 From the point of view of the parent zone above the splitting zone or 320 above the upper of the two combining zones, there is no change. When 321 a zone is split by introducing a cut, the newly created child must be 322 properly configured. 324 However, from the point of view of a child of the splitting zone 325 which becomes a grandchild or a grandchild that becomes a child due 326 to joinder, there is a change in parent name. Therefore, in the 327 normal case, there is a change in parent KEY(s). Unless the entity 328 that handles rollovers for the zone whose parent name has changed is 329 appropriately updated, future automated rollovers will fail because 330 they will be sent to the old parent. 332 For this reason and so that other consistency checks can be made, the 333 parent SOA and SIG(SOA) are always included in the Answer section of 334 rollover NOTIFY requests and in ROLLOVER responsess. For automated 335 rollover to the new cut or joined state to work, these SOAs must be 336 signed with old KEY(s) of the former parent so the signatures can be 337 validated by the zone whose parent name is changing. In the case of 338 a joinder, if the private key of the pinched out middle zone is not 339 available, then manual update of the former grandchild, now child, 340 will be necessary. In the case of introducing a cut, operational 341 coordination with the former parent, now grandparent, signing the 342 initial updates to the former child, now grandchild, will be needed 343 to automate the reconfiguration of the zones. 345 5. Security Considerations 347 The security of ROLLOVER or UPDATE requests is essential, otherwise 348 false children could steal parental authorization or a false parent 349 could cause a child to install an invalid signature on its zone key, 350 etc. 352 A ROLLOVER request can be authenticated by request SIG(s)under the 353 old zone KEY(s) of the requestor [RFC 2535]. The response SHOULD 354 have transaction SIG(s) under the old zone KEY(s) of the responder. 356 Alternatively, if there is a prior arrangement between a child and a 357 parent, ROLLOVER requests and responses can be secured and 358 authenticated using TSIG [RFC 2845]. 360 A server that implements online signing SHOULD have the ability to 361 black list a zone and force manual processing or demand that a 362 particular signature be used to generate the ROLLOVER request. This 363 is to allow ROLLOVER to be used even after a private key has been 364 compromised. 366 6. IANA Considerations 368 The DNS operation code (TBD) is assigned to ROLLOVER. 370 The Service Name (TBD) is assigned to the DNS key rollover service. 372 There are no other IANA considerations in this document. 374 References 376 [RFC 1034] - "Domain names - concepts and facilities", P. 377 Mockapetris, 11/01/1987. 379 [RFC 1035] - "Domain names - implementation and specification", P. 380 Mockapetris, 11/01/1987. 382 [RFC 1996] - "A Mechanism for Prompt Notification of Zone Changes 383 (DNS NOTIFY)", P. Vixie, August 1996. 385 [RFC 2119] - "Key words for use in RFCs to Indicate Requirement 386 Levels", S. Bradner. March 1997. 388 [RFC 2136] - "Dynamic Updates in the Domain Name System (DNS 389 UPDATE)", P. Vixie, Ed., S. Thomson, Y. Rekhter, J. Bound. April 390 1997. 392 [RFC 2535] - "Domain Name System Security Extensions", D. Eastlake. 393 March 1999. 395 [RFC 2541] - "DNS Security Operational Considerations", D. Eastlake. 396 March 1999. 398 [RFC 2782] - "A DNS RR for specifying the location of services (DNS 399 SRV)", A. Gulbrandsen, P. Vixie, L. Esibov. February 2000. 401 [RFC 2845] - "Secret Key Transaction Authentication for DNS (TSIG)", 402 P. Vixie, O. Gundmundsson, D. Eastlake, B. Wellington. May 2000. 404 Authors Address 406 Donald E. Eastlake 3rd 407 Motorola 408 155 Beaver Street 409 Milford, MA 01757 USA 411 Telephone: +1 508-261-5434 (w) 412 +1 508-634-2066 (h) 413 FAX: +1 508-261-4447 (w) 414 EMail: Donald.Eastlake@motorola.com 416 Mark Andrews 417 Nominum, Inc. 418 1 Seymour Street 419 Dundas Valley, NSW 2117 420 AUSTRALIA 422 Telephone: +61-2-9871-4742 423 Email: Mark.Andrews@nominum.com 425 Expiration and File Name 427 This draft expires in June 2001 429 Its file name is draft-ietf-dnsop-rollover-01.txt.