idnits 2.17.1 draft-mekking-dnsop-kasp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (July 4, 2014) is 3584 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'REF' is mentioned on line 126, but not defined Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 DNSOP J. Lundstroem 3 Internet-Draft .SE 4 Intended status: Experimental W. Mekking 5 Expires: January 5, 2015 NLnet Labs 6 July 4, 2014 8 DNSSEC Key and Signing Policies 9 draft-mekking-dnsop-kasp-00 11 Abstract 13 This document describes how key policies should look like. 15 Status of This Memo 17 This Internet-Draft is submitted in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF). Note that other groups may also distribute 22 working documents as Internet-Drafts. The list of current Internet- 23 Drafts is at http://datatracker.ietf.org/drafts/current/. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 This Internet-Draft will expire on January 5, 2015. 32 Copyright Notice 34 Copyright (c) 2014 IETF Trust and the persons identified as the 35 document authors. All rights reserved. 37 This document is subject to BCP 78 and the IETF Trust's Legal 38 Provisions Relating to IETF Documents 39 (http://trustee.ietf.org/license-info) in effect on the date of 40 publication of this document. Please review these documents 41 carefully, as they describe your rights and restrictions with respect 42 to this document. Code Components extracted from this document must 43 include Simplified BSD License text as described in Section 4.e of 44 the Trust Legal Provisions and are provided without warranty as 45 described in the Simplified BSD License. 47 Table of Contents 49 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 50 1.1. Key Words . . . . . . . . . . . . . . . . . . . . . . . . 2 51 1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 2 52 1.3. Data Modeling . . . . . . . . . . . . . . . . . . . . . . 3 53 1.3.1. Data Modeling Types . . . . . . . . . . . . . . . . . 3 54 1.3.2. Data Modeling Arguments . . . . . . . . . . . . . . . 3 55 2. KASP Contents . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Preamble . . . . . . . . . . . . . . . . . . . . . . . . 3 57 2.1.1. Policies . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1.1.1. Signatures . . . . . . . . . . . . . . . . . . . 4 59 2.1.1.2. Authenticated Denial of Existence . . . . . . . . 6 60 2.1.1.3. Keys . . . . . . . . . . . . . . . . . . . . . . 8 61 2.1.1.4. Zone . . . . . . . . . . . . . . . . . . . . . . 11 62 2.1.1.5. Parent . . . . . . . . . . . . . . . . . . . . . 13 63 3. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 64 3.1. Informative References . . . . . . . . . . . . . . . . . 14 65 3.2. Normative References . . . . . . . . . . . . . . . . . . 14 66 Appendix A. Changelog . . . . . . . . . . . . . . . . . . . . . 16 68 1. Introduction 70 A key and signing policy (KASP) defines a DNSSEC [RFC4033] [RFC4034] 71 [RFC4035] policy for one or more zones. 73 1.1. Key Words 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY" and "OPTIONAL" in this 77 document are to be interpreted as described in [RFC2119]. 79 1.2. Terminology 81 The reader is assumed to be familiar with DNSSEC described in 82 [RFC4033] [RFC4034] [RFC4035], [RFC5155] and [RFC6781]. 84 The following terminology is used throughout this document: 86 KASP: Key And Signing Policy, describes a DNSSEC policy that can be 87 applied to one or more zones. 89 A key and signing policy can be expressed in any format. This 90 document uses XML as example. 92 1.3. Data Modeling 94 1.3.1. Data Modeling Types 96 This document reuses the modeling types described in [RFC6020]. 98 The following modeling types are used: 100 container: A container node does not have a value, but it has a list 101 of child nodes in the data tree. The child nodes are defined in 102 the container's substatements. 104 leaf: A leaf node has a value, but no child nodes in the data tree. 105 A leaf node exists in zero or one instances in the data tree. 107 list: The "list" statement is used to define an interior data node 108 in the schema tree. A list node may exist in multiple instances 109 in the data tree. Each such instance is known as a list entry. 111 choice: The "choice" statement defines a set of alternatives, only 112 one of which may exist at any one time. A choice node does not 113 exist in the data tree. 115 A choice consists of a number of branches, defined with the "case" 116 substatement. Each branch contains a number of child nodes. The 117 nodes from at most one of the choice's branches exist at the same 118 time. 120 1.3.2. Data Modeling Arguments 122 The following arguments are used: 124 string: A string. 126 duration: A duration, as specified in ISO 8601 [REF]. 128 empty: An empty type. 130 integer: An integer. 132 2. KASP Contents 134 2.1. Preamble 136 All policies MUST be enclosed in a KASP container. 138 container KASP { 139 list Policy { ... } 140 } 142 A KASP container MUST contain a sequence of policy entries and MUST 143 NOT contain any other modeling types. 145 2.1.1. Policies 147 Each policy MUST have a "name" leaf which contains the name of the 148 policy. The name is used to link a policy and the zones signed using 149 it; each policy MUST have a unique name. A policy named "default" 150 MAY be used to associate with all zones that do not have a policy 151 explicitly configured. A policy SHOULD have a description associated 152 with it. Furthermore, a policy MUST have the containers Signatures, 153 Denial, Keys, Zone and Parent. These containers are described in the 154 forthcoming sections. 156 list Policy { 157 key "name"; 158 leaf name { 159 mandatory true; 160 type string; 161 } 162 leaf description { 163 type string; 164 } 165 container Signatures { ... } 166 container Denial { ... } 167 container Keys { ... } 168 container Zone { ... } 169 container Parent { ... } 170 } 172 2.1.1.1. Signatures 174 A Signatures container defines the policy parameters for creating 175 RRSIG records and MUST be included. It MUST contain the following 176 leaf nodes: Resign, Refresh, InceptionOffset. It MAY have a leaf 177 node Jitter. It MUST contain a Validity container that includes leaf 178 nodes for the validity periods of certain type of resource record 179 sets (RRsets). The Default leaf node sets the validity period for 180 all RRsets that do not have a specific leaf node in this Validity 181 container. The Denial leaf node sets the validity period for all 182 NSEC and NSEC3 RRsets. 184 The Validity container MUST include leaf nodes Default and Denial and 185 MAY include other leaf nodes to differentiate between even more types 186 of RRsets. 188 container Signatures { 189 leaf Resign { 190 mandatory true; 191 type duration; 192 } 193 leaf Refresh { 194 mandatory true; 195 type duration; 196 } 197 leaf Jitter { 198 type duration; 199 } 200 leaf InceptionOffset { 201 mandatory true; 202 type duration; 203 } 204 container Validity { 205 leaf Default { 206 mandatory true; 207 type duration; 208 } 209 leaf Denial { 210 mandatory true; 211 type duration; 212 } 213 } 214 } 216 Here: 218 1. Resign - the re-sign interval, which is the interval when the 219 signer MUST re-sign the zone. 221 2. Refresh - the refresh interval, detailing when a signature MUST 222 be refreshed. As signatures are typically valid for much longer 223 than the interval between runs of the signer, there is no need to 224 re-generate the signatures each time the signer runs. The 225 signature MUST be refreshed when the time until the signature 226 expiration is closer than the refresh interval or when the data 227 has been changed. A value of zero (PT0S) MUST be interpreted as 228 to refresh the signatures each re-sign interval. 230 3. Jitter - If present, the value added to the expiration time of 231 signatures to ensure that not all signatures expire at the same 232 time. The actual value of Jitter to be added MUST be -j + (r % 233 2j), where j is the jitter value from the policy and r a random 234 duration, uniformly ranging between -j and j, is added to 235 signature validity period to get the signature expiration time. 237 4. InceptionOffset - a duration that MUST be subtracted from the 238 time at which a record is signed to give the start time of the 239 record. This is required to allow for clock skew between the 240 signing system and the system on which the signature is checked. 241 Without it, the possibility exists that the checking system could 242 retrieve a signature whose start time is later than the current 243 time. 245 5. Validity - groups two or more elements of information related to 246 how long the signatures are valid for - Denial is the validity 247 period for all NSEC and NSEC3 RRsets, Default is the validity 248 period for all other RRset. 250 [MM: Add MaxZoneTTL] 252 The relationship between these elements is shown [RFC6781], 253 Figure 11. 255 2.1.1.2. Authenticated Denial of Existence 257 Authenticated denial of existence information is included within a 258 Denial container. It MUST contain either an empty leaf node NSEC or 259 a container NSEC3. A NSEC3 container MUST include a leaf node for 260 TTL and Resalt and MUST include a container Hash. Additionally, it 261 MAY include an OptOut leaf node. 263 The Hash container MUST include three leaf nodes: Algorithm, 264 Iterations and SaltLength. 266 container Denial { 267 choice RRtype { 268 case plain { 269 leaf NSEC { 270 mandatory true; 271 type empty; 272 } 273 } 274 case hashed { 275 container NSEC3 { 276 leaf TTL { 277 mandatory true; 278 type duration; 279 } 280 leaf OptOut { 281 type empty; 282 } 283 leaf Resalt { 284 mandatory true; 285 type duration; 286 } 287 container Hash { 288 leaf Algorithm { 289 mandatory true; 290 type integer; 291 } 292 leaf Iterations { 293 mandatory true; 294 type integer; 295 } 296 leaf SaltLength { 297 mandatory true; 298 type integer; 299 } 300 } 301 } 302 } 303 } 305 If NSEC is used, zones with this policy MUST include NSEC records 306 when signing the zone. If NSEC3 is used, zones with this policy MUST 307 include NSEC3 and NSEC3PARAM records with the appropriate policy 308 values: 310 1. TTL - if present, the TTL for the NSEC3PARAM resource record MUST 311 be set to this value. If not present, PT0S (0) SHOULD be used as 312 TTL. 314 2. OptOut - if present, all included NSEC3 records SHOULD set the 315 Opt-Out bit. The signer SHOULD NOT include NSEC3 records for 316 insecure delegations. 318 3. Resalt - A new salt value MUST be generated each Resalt interval 319 value. 321 4. Algorithm, Iterations, SaltLength MUST be used as the parameters 322 to the hash algorithm. 324 The choice and case modeling types are not included in the actual 325 data tree. In the case that NSEC is used, the XML example would be: 327 328 329 331 2.1.1.3. Keys 333 Parameters relating to keys can be found in Keys container. This 334 container MUST include leaf node for TTL, and MAY include leaf nodes 335 for PublishSafety, RetireSafety, ShareKeys and Purge. Furthermore, 336 it MAY include a KSK list, a ZSK list and/or a CSK list. The latter 337 indicates that a Single-Type Signing Scheme is used. If no such 338 lists are included in the policy, the zone remains unsigned. 340 container Keys { 341 leaf TTL { 342 mandatory true; 343 type duration; 344 } 345 leaf PublishSafety { 346 type duration; 347 } 348 leaf RetireSafety { 349 type duration; 350 } 351 leaf ShareKeys { 352 type empty; 353 } 354 leaf Purge { 355 type duration; 356 } 357 list KSK { ... } 358 list ZSK { ... } 359 list CSK { ... } 360 } 361 The leaf nodes specify the following behavior: 363 1. TTL - This value MUST be used as the TTL of the DNSKEY resource 364 records. 366 2. PublishSafety - If present, the publish safety margin is used to 367 give some extra time to cover unforeseen events and MUST be added 368 to the publish interval in key timing equations. 370 3. RetireSafety - If present and similar to PublishSafety, the 371 retire safety margin MUST be added to the retire interval in key 372 timing equations. 374 4. ShareKeys - if multiple zones are associated with the same 375 policy, the presence of a ShareKeys node indicates that a 376 physical key can be shared between zones. 378 5. Purge - if present, keys in the dead state (as defined in key- 379 timing-bis) will be automatically purged from the database after 380 this interval. 382 A CSK, KSK or ZSK list MUST include leaf nodes for Algorithm, Length, 383 Lifetime and Repository. Additionally, they MAY include a RollType 384 leaf, Standby leaf and ManualRollover leaf. A CSK or KSK list MAY 385 also include a RFC5011 leaf. 387 list CSK { 388 leaf Algorithm { 389 mandatory true; 390 type integer; 391 } 392 leaf Length { 393 mandatory true; 394 type integer; 395 } 396 leaf Lifetime { 397 mandatory true; 398 type duration; 399 } 400 leaf Repository { 401 mandatory true; 402 type string; 403 } 404 leaf RollType { 405 type string; 406 } 407 leaf Standby { 408 type empty; 410 } 411 leaf ManualRollover { 412 type empty; 413 } 414 leaf RFC5011 { 415 type empty; 416 } 417 } 419 list KSK { 420 leaf Algorithm { 421 mandatory true; 422 type integer; 423 } 424 leaf Length { 425 mandatory true; 426 type integer; 427 } 428 leaf Lifetime { 429 mandatory true; 430 type duration; 431 } 432 leaf Repository { 433 mandatory true; 434 type string; 435 } 436 leaf RollType { 437 type string; 438 } 439 leaf Standby { 440 type empty; 441 } 442 leaf ManualRollover { 443 type empty; 444 } 445 leaf RFC5011 { 446 type empty; 447 } 448 } 450 list ZSK { 451 leaf Algorithm { 452 mandatory true; 453 type integer; 454 } 455 leaf Length { 456 mandatory true; 457 type integer; 459 } 460 leaf Lifetime { 461 mandatory true; 462 type duration; 463 } 464 leaf Repository { 465 mandatory true; 466 type string; 467 } 468 leaf RollType { 469 type string; 470 } 471 leaf Standby { 472 type empty; 473 } 474 leaf ManualRollover { 475 type empty; 476 } 477 } 479 where: 481 1. Algorithm - this algorithm MUST be used. 483 2. Length - this key length MUST be used. 485 3. Lifetime - determines how long the key SHOULD be used for before 486 it is rolled. 488 4. Repository - determines the location of the physical keys. The 489 corresponding type of keys MUST be stored in this repository. 491 5. Standby - if present, determines the number of standby keys MUST 492 be held in the zone. 494 6. ManualRollover - if present, this indicates that the key rollover 495 MUST NOT occur automatically, it may only be initiated by the 496 operator. 498 7. RFC5011 - if present, this indicates that the key rollover MUST 499 include additional time for key publication and retirement and 500 MUST revoke the predecessor key accordingly. 502 2.1.1.4. Zone 504 The Zone container encloses general information concerning the zone. 505 It MAY include a PropagationDelay leaf and MUST have a SOA container. 507 The SOA container MUST include a TTL leaf, Minimum leaf and Serial 508 leaf. 510 container Zone { 511 leaf PropagationDelay { 512 type duration; 513 } 514 container SOA { 515 leaf TTL { 516 mandatory true; 517 type duration; 518 } 519 leaf Minimum { 520 mandatory true; 521 type duration; 522 } 523 leaf Serial { 524 mandatory true; 525 type string; 526 } 527 } 528 } 530 The PropagationDelay leaf holds the amount of time needed for 531 information changes at the master server for the zone to work its way 532 through to all the secondary servers. The value MAY be used in 533 equations related to key timings during a rollover. If 534 PropagationDelay is not used, a signer MUST use different heuristics 535 to make sure key timings during a rollover are correct, for example 536 by querying the name servers for the required records to exist. 538 The SOA container gives values of parameters for the SOA record in 539 the signed zone. These values will override values set for the SOA 540 record in the unsigned zone file: 542 1. TTL - The TTL of the SOA record MUST be set to the value of the 543 TTL leaf. 545 2. Minimum - The MINIMUM RDATA field of the SOA record MUST be set 546 to the value of the Minimum leaf. 548 3. Serial - The format of the serial number in the signed zone. 549 This is one of: "counter", datecounter, unixtime, keep. 551 When Serial is set to "counter", the SOA serial MUST be incremented 552 by one every re-sign. 554 When Serial is set to "datecounter", the SOA serial MUST be set to 555 YYYYMMDDCC, where YYYYMMDD represents the current date and CC the 556 number of new re-signs that day. If there are more than 100 re-signs 557 a day, the date MUST rollover to the day after and count is reset to 558 00. 560 When Serial is "unixtime", the SOA serial MUST be set to the seconds 561 since the epoch (1970-01-01 UTC). 563 When Serial is "keep" the SOA serial MUST be set to the SERIAL RDATA 564 field of the SOA record in the unsigned zone. If this does not 565 increment the last used serial, a signer MUST NOT produce a signed 566 zone. 568 2.1.1.5. Parent 570 If a DNSSEC zone is in a chain of trust, digest information about the 571 KSKs used in the zone will be published in DS records in the parent 572 zone. To properly roll keys, timing information about the parent 573 zone must be configured in the Parent container. A Parent container 574 MAY include a PropagationDelay leaf, a DS container and a SOA 575 container. The DS container MAY include a TTL leaf and the SOA 576 container MAY include TTL and Minimum leafs. 578 container Parent { 579 leaf PropagationDelay { 580 type duration; 581 } 582 container DS { 583 leaf TTL { 584 type duration; 585 } 586 } 587 container SOA { 588 leaf TTL { 589 type duration; 590 } 591 leaf Minimum { 592 type duration; 593 } 594 } 595 } 597 Here, the PropagationDelay leaf configures how long it takes to get a 598 DS record published in the parent zone after submitting the DNSKEY or 599 DS record to the parent zone manager. The value SHOULD be used in 600 equations related to key timings during a rollover. If 601 PropagationDelay is not used, a signer MUST use different heuristics 602 to make sure key timings during a rollover are correct, for example 603 by querying the name servers for the required records to exist. 605 The DS and SOA containers give values of parameters for the DS record 606 and SOA record in the parent zone. These values SHOULD be used in 607 equations related to key timings during a rollover. If these values 608 are not used, a signer MUST query the parent name servers in order to 609 retrieve the correct values. 611 A before: 613 1. TTL - The TTL of the DS and SOA records MUST be set to the value 614 of the corresponding TTL leaf. 616 2. Minimum - The MINIMUM RDATA field of the SOA record MUST be set 617 to the value of the Minimum leaf. 619 3. References 621 3.1. Informative References 623 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 624 Rose, "DNS Security Introduction and Requirements", RFC 625 4033, March 2005. 627 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 628 Rose, "Resource Records for the DNS Security Extensions", 629 RFC 4034, March 2005. 631 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 632 Rose, "Protocol Modifications for the DNS Security 633 Extensions", RFC 4035, March 2005. 635 [RFC5155] Laurie, B., Sisson, G., Arends, R., and D. Blacka, "DNS 636 Security (DNSSEC) Hashed Authenticated Denial of 637 Existence", RFC 5155, March 2008. 639 [RFC6781] Kolkman, O., Mekking, W., and R. Gieben, "DNSSEC 640 Operational Practices, Version 2", RFC 6781, December 641 2012. 643 3.2. Normative References 645 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 646 Requirement Levels", BCP 14, RFC 2119, March 1997. 648 [RFC6020] Bjorklund, M., "YANG - A Data Modeling Language for the 649 Network Configuration Protocol (NETCONF)", RFC 6020, 650 October 2010. 652 Appendix A. Changelog 654 o Initial version 656 Authors' Addresses 658 Jerry Lundstroem 659 .SE 660 Ringvaegen 100 661 Box 7399 662 Stockholm 103 91 663 SE 665 EMail: jerry.lundstrom@iis.se 666 URI: http://www.iis.se/ 668 W. (Matthijs) Mekking 669 NLnet Labs 670 Science Park 400 671 Amsterdam 1098 XH 672 NL 674 EMail: matthijs@nlnetlabs.nl 675 URI: http://www.nlnetlabs.nl/