1 2 3 4Intended Status: Informational O. Gudmundsson 5Network Working Group OGUD Consulting LLC 6Internet-Draft J. Ihren 7Expires: August 21, 2008 AAB 8 February 18, 2008 9 10 11 Names of States in the life of a DNSKEY 12 draft-gudmundsson-life-of-dnskey-00 13 14Status of this Memo 15 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 25 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 30 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 33 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 36 37 This Internet-Draft will expire on August 21, 2008. 38 39Copyright Notice 40 41 Copyright (C) The IETF Trust (2008). 42 43 44 45 46 47 48 49 50 51 52 53 54 55Gudmundsson & Ihren Expires August 21, 2008 [Page 1] 56 57Internet-Draft DNSSEC Key life stages. February 2008 58 59 60Abstract 61 62 This document recommends a specific terminology to use when 63 expressing the state that a DNSKEY is in at particular time. This 64 does not affect how the protocol operates in any way. 65 66 67Table of Contents 68 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 70 2. DNSKEY timeline . . . . . . . . . . . . . . . . . . . . . . . 4 71 3. Life stages of a DNSKEY . . . . . . . . . . . . . . . . . . . 5 72 3.1. Generated . . . . . . . . . . . . . . . . . . . . . . . . 5 73 3.2. Published . . . . . . . . . . . . . . . . . . . . . . . . 5 74 3.2.1. Pre-Publication . . . . . . . . . . . . . . . . . . . 5 75 3.2.2. Out-Of-Band Publication . . . . . . . . . . . . . . . 5 76 3.3. Active . . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 3.4. Retired . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 3.5. Removed . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 3.5.1. Lame . . . . . . . . . . . . . . . . . . . . . . . . . 6 80 3.5.2. Stale . . . . . . . . . . . . . . . . . . . . . . . . 6 81 3.6. Revoked . . . . . . . . . . . . . . . . . . . . . . . . . 6 82 4. Security considerations . . . . . . . . . . . . . . . . . . . 7 83 5. IANA considerations . . . . . . . . . . . . . . . . . . . . . 8 84 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 9 85 6.1. Normative References . . . . . . . . . . . . . . . . . . . 9 86 6.2. Informative References . . . . . . . . . . . . . . . . . . 9 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 10 88 Intellectual Property and Copyright Statements . . . . . . . . . . 11 89 90 91 92 93 94 95 96 97 98 99 100 101 102 103 104 105 106 107 108 109 110 111Gudmundsson & Ihren Expires August 21, 2008 [Page 2] 112 113Internet-Draft DNSSEC Key life stages. February 2008 114 115 1161. Introduction 117 118 When the editors of this document where comparing their DNSSEC key 119 management projects they discovered that they where discussing 120 roughly the same thing but using different terminology. 121 122 This document presents a unified terminology to use when describing 123 the current state of a DNSKEY. 124 125 The DNSSEC standards documents ([1], [2] and [3]) do not address the 126 required states for the key management of a DNSSEC key. The DNSSEC 127 Operational Practices [4] document does propose that keys be 128 published before use but uses inconsistent or confusing terms. This 129 document assumes basic understanding of DNSSEC and key management. 130 131 The terms proposed in this document attempt to avoid any confusion 132 and make the states of keys to be as clear as possible. The terms 133 used in this document are intended as a operational supplement to the 134 terms defined in Section 2 of [1]. 135 136 To large extent this discussion is motivated by Trust anchor keys but 137 the same terminology can be used for zone signing keys. 138 139 140 141 142 143 144 145 146 147 148 149 150 151 152 153 154 155 156 157 158 159 160 161 162 163 164 165 166 167Gudmundsson & Ihren Expires August 21, 2008 [Page 3] 168 169Internet-Draft DNSSEC Key life stages. February 2008 170 171 1722. DNSKEY timeline 173 174 The model in this document is that keys progress through a state 175 machine along a one-way path, keys never move to an earlier states. 176 177 178 179 GENERATED----------> PUBLISHED ---> ACTIVE ---> RETIRED --> REMOVED 180 | ^ | | | ^ 181 | | | | v | 182 +--> Pre-PUBLISHED--+ +--------+---------> REVOKED ---+ 183 184 185 DNSKEY time line. 186 187 There are few more states that are defined below but these apply only 188 to the publisher of TA's and the consumer of TA's. Two of these are 189 sub-sets of the Published state, the other two are error states. 190 191 192 193 194 195 196 197 198 199 200 201 202 203 204 205 206 207 208 209 210 211 212 213 214 215 216 217 218 219 220 221 222 223Gudmundsson & Ihren Expires August 21, 2008 [Page 4] 224 225Internet-Draft DNSSEC Key life stages. February 2008 226 227 2283. Life stages of a DNSKEY 229 2303.1. Generated 231 232 Once a key is generated it enters state Generated and stays there 233 until the next state. While in this state only the owner of the key 234 is aware of its existence and can prepare for its future use. 235 2363.2. Published 237 238 Once the key is added to the DNSKEY set of a zone the key is there 239 for the world to see, or published. The key needs to remain in this 240 state for some time to propagate to all validators that have cached 241 the prior version of the DNSKEY set. In the case of KSK the key 242 should remain in this state for a longer time as documented in DNSSEC 243 Timers RFC [5]. 244 2453.2.1. Pre-Publication 246 247 In certain circumstances a zone owner may want to give out a new 248 Trust Anchor before exposing the actual public key. In this case the 249 zone can publish a DS record of the key. This allows others to 250 configure the trust anchor but will not be able to use the key until 251 the key is published in the DNSKEY RRset. 252 2533.2.2. Out-Of-Band Publication 254 255 In certain circumstances a domain may want to give out a new Trust 256 Anchor outside DNS to give others a long lead time to configure the 257 new key as trust anchor. The reason people may want to do this is to 258 keep the size of the DNSKEY set smaller and only add new trust anchor 259 just before the key goes into use. One likely use for this is the 260 DNS "." root key as it does not have a parent that can publish a DS 261 record for it. The publication mechanism does not matter it can be 262 any one of web-site, advertisement in Financial Times and other 263 international publication, e-mail to DNS related mailing lists, etc.. 264 2653.3. Active 266 267 The key is in ACTIVE state while it is actively signing data in the 268 zone it resides in. It is one of the the keys that are signing the 269 zone or parts of the zone. 270 2713.4. Retired 272 273 When the key is no longer used for signing the zone it enters state 274 Retired. In this state there may still be signatures by the key in 275 cached data from the zone available at recursive servers, but the 276 277 278 279Gudmundsson & Ihren Expires August 21, 2008 [Page 5] 280 281Internet-Draft DNSSEC Key life stages. February 2008 282 283 284 authoritative servers for the zone do no longer carry any signatures 285 generated by the key. 286 2873.5. Removed 288 289 Once the key is removed from the DNSKEY RRset it enters the state 290 Removed. At this point all signatures by the key that may still be 291 temporarily valid will fail to verify once the validator refreshes 292 the DNSKEY RRset in its memory. 293 294 Therefore "removal" of a key is typically not done until all the 295 cached signatures have expired. Entering this state too early may 296 cause number of validators to end up with STALE Trust Anchors. 297 2983.5.1. Lame 299 300 A Trust Anchor is Lame if the parent continues to publish DS pointing 301 to the key after it has been removed from the DNSKEY RRset. A Trust 302 Anchor is arguably Lame if there are no signatures by a Retired KSK 303 in the zone. 304 3053.5.2. Stale 306 307 A Stale Trust Anchor is an old TA that remains in a validators list 308 of active key(s) after the key has been removed from the zone's 309 DNSKEY RRset. 310 3113.6. Revoked 312 313 There are times when a zone wants to signal that a particular key 314 should not be used at all. The mechanism to do this is to set the 315 REVOKE bit [5]. Any key in any of the while the key is the DNSSKEY 316 set can be exited to Revoked state. After some time in the Revoke 317 state the key will be Removed. 318 319 320 321 322 323 324 325 326 327 328 329 330 331 332 333 334 335Gudmundsson & Ihren Expires August 21, 2008 [Page 6] 336 337Internet-Draft DNSSEC Key life stages. February 2008 338 339 3404. Security considerations 341 342 TBD 343 344 345 346 347 348 349 350 351 352 353 354 355 356 357 358 359 360 361 362 363 364 365 366 367 368 369 370 371 372 373 374 375 376 377 378 379 380 381 382 383 384 385 386 387 388 389 390 391Gudmundsson & Ihren Expires August 21, 2008 [Page 7] 392 393Internet-Draft DNSSEC Key life stages. February 2008 394 395 3965. IANA considerations 397 398 This document does not have any IANA actions. 399 400 401 402 403 404 405 406 407 408 409 410 411 412 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447Gudmundsson & Ihren Expires August 21, 2008 [Page 8] 448 449Internet-Draft DNSSEC Key life stages. February 2008 450 451 4526. References 453 4546.1. Normative References 455 4566.2. Informative References 457 458 [1] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 459 "DNS Security Introduction and Requirements", RFC 4033, 460 March 2005. 461 462 [2] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 463 "Resource Records for the DNS Security Extensions", RFC 4034, 464 March 2005. 465 466 [3] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 467 "Protocol Modifications for the DNS Security Extensions", 468 RFC 4035, March 2005. 469 470 [4] Kolkman, O. and R. Gieben, "DNSSEC Operational Practices", 471 RFC 4641, September 2006. 472 473 [5] StJohns, M., "Automated Updates of DNS Security (DNSSEC) Trust 474 Anchors", RFC 5011, September 2007. 475 476 477 478 479 480 481 482 483 484 485 486 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503Gudmundsson & Ihren Expires August 21, 2008 [Page 9] 504 505Internet-Draft DNSSEC Key life stages. February 2008 506 507 508Authors' Addresses 509 510 Olafur Gudmundsson 511 OGUD Consulting LLC 512 3821 Village Park Drive 513 Chevy Chase, MD 20815 514 USA 515 516 Email: ogud@ogud.com 517 518 519 Johan Ihren 520 Automatica, AB 521 Bellmansgatan 30 522 Stockholm, SE-118 47 523 Sweden 524 525 Email: johani@automatica.se 526 527 528 529 530 531 532 533 534 535 536 537 538 539 540 541 542 543 544 545 546 547 548 549 550 551 552 553 554 555 556 557 558 559Gudmundsson & Ihren Expires August 21, 2008 [Page 10] 560 561Internet-Draft DNSSEC Key life stages. February 2008 562 563 564Full Copyright Statement 565 566 Copyright (C) The IETF Trust (2008). 567 568 This document is subject to the rights, licenses and restrictions 569 contained in BCP 78, and except as set forth therein, the authors 570 retain all their rights. 571 572 This document and the information contained herein are provided on an 573 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 574 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 575 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 576 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 577 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 578 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 579 580 581Intellectual Property 582 583 The IETF takes no position regarding the validity or scope of any 584 Intellectual Property Rights or other rights that might be claimed to 585 pertain to the implementation or use of the technology described in 586 this document or the extent to which any license under such rights 587 might or might not be available; nor does it represent that it has 588 made any independent effort to identify any such rights. Information 589 on the procedures with respect to rights in RFC documents can be 590 found in BCP 78 and BCP 79. 591 592 Copies of IPR disclosures made to the IETF Secretariat and any 593 assurances of licenses to be made available, or the result of an 594 attempt made to obtain a general license or permission for the use of 595 such proprietary rights by implementers or users of this 596 specification can be obtained from the IETF on-line IPR repository at 597 http://www.ietf.org/ipr. 598 599 The IETF invites any interested party to bring to its attention any 600 copyrights, patents or patent applications, or other proprietary 601 rights that may cover technology that may be required to implement 602 this standard. Please address the information to the IETF at 603 ietf-ipr@ietf.org. 604 605 606Acknowledgment 607 608 Funding for the RFC Editor function is provided by the IETF 609 Administrative Support Activity (IASA). 610 611 612 613 614 615Gudmundsson & Ihren Expires August 21, 2008 [Page 11] 616 617