idnits 2.17.1 draft-gould-rfc4310bis-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 : ---------------------------------------------------------------------------- == 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 copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 3, 2010) is 5165 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) ** Obsolete normative reference: RFC 3757 (Obsoleted by RFC 4033, RFC 4034, RFC 4035) -- Obsolete informational reference (is this intentional?): RFC 4310 (Obsoleted by RFC 5910) Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gould 3 Internet-Draft S. Hollenbeck 4 Obsoletes: 4310 (if approved) VeriSign, Inc. 5 Intended status: Standards Track March 3, 2010 6 Expires: September 4, 2010 8 Domain Name System (DNS) Security Extensions Mapping for the Extensible 9 Provisioning Protocol (EPP) 10 draft-gould-rfc4310bis-07 12 Abstract 14 This document describes an Extensible Provisioning Protocol (EPP) 15 extension mapping for the provisioning and management of Domain Name 16 System security extensions (DNSSEC) for domain names stored in a 17 shared central repository. Specified in XML, this mapping extends 18 the EPP domain name mapping to provide additional features required 19 for the provisioning of DNS security extensions. 21 This document incorporates feedback from early implementers on the 22 PROVREG mail list and users. 24 This document obsoletes RFC 4310. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on September 4, 2010. 49 Copyright Notice 51 Copyright (c) 2010 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 79 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 80 2. Migrating from RFC 4310 . . . . . . . . . . . . . . . . . . . 4 81 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5 82 3.1. Delegation Signer Information . . . . . . . . . . . . . . 5 83 3.1.1. Public Key Information . . . . . . . . . . . . . . . . 5 84 3.2. Booleans . . . . . . . . . . . . . . . . . . . . . . . . . 5 85 3.3. Maximum Signature Lifetime . . . . . . . . . . . . . . . . 6 86 4. DS Data Interface and Key Data Interface . . . . . . . . . . . 6 87 4.1. DS Data Interface . . . . . . . . . . . . . . . . . . . . 7 88 4.2. Key Data Interface . . . . . . . . . . . . . . . . . . . . 8 89 4.3. Example DS Data Interface and Key Data Interface . . . . . 8 90 5. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 9 91 5.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . . 9 92 5.1.1. EPP Command . . . . . . . . . . . . . . . . . 9 93 5.1.2. EPP Command . . . . . . . . . . . . . . . . . . 9 94 5.1.3. EPP Command . . . . . . . . . . . . . . . . 14 95 5.2. EPP Transform Commands . . . . . . . . . . . . . . . . . . 14 96 5.2.1. EPP Command . . . . . . . . . . . . . . . . . 14 97 5.2.2. EPP Command . . . . . . . . . . . . . . . . . 17 98 5.2.3. EPP Command . . . . . . . . . . . . . . . . . 18 99 5.2.4. EPP Command . . . . . . . . . . . . . . . . 18 100 5.2.5. EPP Command . . . . . . . . . . . . . . . . . 18 101 6. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 25 102 7. Internationalization Considerations . . . . . . . . . . . . . 29 103 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 29 104 9. Security Considerations . . . . . . . . . . . . . . . . . . . 30 105 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 31 106 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 31 107 11.1. Normative References . . . . . . . . . . . . . . . . . . . 31 108 11.2. Informative References . . . . . . . . . . . . . . . . . . 32 109 Appendix A. Changes from RFC 4310 . . . . . . . . . . . . . . . . 33 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 35 112 1. Introduction 114 This document describes an extension mapping for version 1.0 of the 115 Extensible Provisioning Protocol (EPP) described in RFC 5730 116 [RFC5730]. This mapping, an extension of the domain name mapping 117 described in RFC 5731 [RFC5731], is specified using the Extensible 118 Markup Language (XML) 1.0 [W3C.REC-xml-20001006] and XML Schema 119 notation ([W3C.REC-xmlschema-1-20010502], 120 [W3C.REC-xmlschema-2-20010502]). 122 The EPP core protocol specification [RFC5730] provides a complete 123 description of EPP command and response structures. A thorough 124 understanding of the base protocol specification is necessary to 125 understand the mapping described in this document. Familiarity with 126 the Domain Name System (DNS) described in RFC 1034 [RFC1034] and RFC 127 1035 [RFC1035] and with DNS security extensions described in RFC 4033 128 [RFC4033], RFC 4034 [RFC4034], and RFC 4035 [RFC4035] is required to 129 understand the DNS security concepts described in this document. 131 The EPP mapping described in this document specifies a mechanism for 132 the provisioning and management of DNS security extensions in a 133 shared central repository. Information exchanged via this mapping 134 can be extracted from the repository and used to publish DNSSEC 135 delegation signer (DS) resource records as described in RFC 4034 136 [RFC4034]. 138 This document obsoletes RFC 4310 [RFC4310]; thus secDNS-1.1 as 139 defined in this document deprecates secDNS-1.0 [RFC4310]. The 140 motivation behind obsoleting RFC 4310 [RFC4310] includes: 142 - Address the issue with removing DS data based on the non-unique 143 element. The client should explicitly specify the 144 DS data to remove using all four elements that is 145 guaranteed to be unique. 146 - Add the ability to add and remove elements in a 147 single command. This makes it consistent with RFC 5731 [RFC5731]. 148 - Clarify and correct the usage of the element. RFC 149 4310 [RFC4310] defined the as a replace of the DS 150 data. This is inconsistent with RFC 5731 [RFC5731] where a 151 is used to change the values of the domain 152 attributes. 153 - Add support for the Key Data Interface described in Section 4.2 154 for "thick" DNSSEC servers that accept only key data and generate 155 the associated DS data. 157 1.1. Conventions Used in This Document 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 160 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 161 document are to be interpreted as described in BCP 14, RFC 2119 162 [RFC2119]. 164 In examples, "C:" represents lines sent by a protocol client, and 165 "S:" represents lines returned by a protocol server. "////" is used 166 to note element values that have been shortened to better fit page 167 boundaries. Indentation and white space in examples is provided only 168 to illustrate element relationships and is not a mandatory feature of 169 this protocol. 171 XML is case sensitive. Unless stated otherwise, XML specifications 172 and examples provided in this document MUST be interpreted in the 173 character case presented in order to develop a conforming 174 implementation. 176 secDNS-1.0 is used as an abbreviation for 177 urn:ietf:params:xml:ns:secDNS-1.0 and secDNS-1.1 is used as an 178 abbreviation for urn:ietf:params:xml:ns:secDNS-1.1. 180 2. Migrating from RFC 4310 182 This section includes implementation recommendations for clients and 183 servers in migrating from secDNS-1.0 [RFC4310] to secDNS-1.1. 185 As this document deprecates RFC 4310 [RFC4310], if a server announces 186 support for both secDNS-1.0 [RFC4310] and secDNS-1.1 in the EPP 187 greeting, clients supporting both versions SHOULD prefer secDNS-1.1. 189 A server SHOULD do the following to help clients migrate from 190 secDNS-1.0 [RFC4310] to secDNS-1.1 as defined in this document. 192 1. A server migrating from secDNS-1.0 [RFC4310] to secDNS-1.1 SHOULD 193 support both versions (i.e. secDNS-1.0 and secDNS-1.1) for a 194 reasonable migration period. 196 2. The version of the element to be returned by the 197 server in the response to a SHOULD depend on the 198 elements (indicating the secDNS extension) the client 199 included in the EPP command using the following mapping: 201 - Return version secDNS-1.1 of the element if 202 urn:ietf:params:xml:ns:secDNS-1.1 was included as an 203 element in the EPP command, independent of whether 204 urn:ietf:params:xml:ns:secDNS-1.0 is also included as an 205 element in the EPP command. 207 - Return version secDNS-1.0 of the element if 208 urn:ietf:params:xml:ns:secDNS-1.0 but not 209 urn:ietf:params:xml:ns:secDNS-1.1 was included as an 210 element in the EPP command. 212 - Don't return the element if neither 213 urn:ietf:params:xml:ns:secDNS-1.0 or 214 urn:ietf:params:xml:ns:secDNS-1.1 was included as an 215 element in the EPP command. 217 3. Object Attributes 219 This extension adds additional elements to the EPP domain name 220 mapping [RFC5731]. Only those new elements are described here. 222 3.1. Delegation Signer Information 224 Delegation signer (DS) information is published by a DNS server to 225 indicate that a child zone is digitally signed and that the parent 226 zone recognizes the indicated key as a valid zone key for the child 227 zone. A DS resource record (RR) contains four fields: a key tag 228 field, a key algorithm number octet, an octet identifying a digest 229 algorithm, and a digest field. See RFC 4034 [RFC4034] for specific 230 field formats. 232 3.1.1. Public Key Information 234 Public key information provided by a client maps to the DNSKEY RR 235 presentation field formats described in section 2.2 of RFC 4034 236 [RFC4034]. A DNSKEY RR contains four fields: flags, a protocol 237 octet, an algorithm number octet, and a public key. 239 3.2. Booleans 241 Boolean values MUST be represented in the XML Schema format described 242 in Part 2 of the W3C XML Schema recommendation 243 [W3C.REC-xmlschema-2-20010502]. 245 3.3. Maximum Signature Lifetime 247 Maximum signature lifetime (maxSigLife) is an OPTIONAL child 248 preference for the number of seconds after signature generation when 249 the parent's signature on the DS information provided by the child 250 will expire. The maxSigLife value applies to the RRSIG resource 251 record (RR) over the DS RRset. See section 3 of RFC 4034 [RFC4034] 252 for information on the RRSIG resource record (RR). 254 The maximum signature lifetime is represented using the element. The maxSigLife value MUST be represented in 256 seconds using an extended XML Schema "int" format. The base "int" 257 format, which allows negative numbers, is described in Part 2 of the 258 W3C XML Schema recommendation [W3C.REC-xmlschema-2-20010502]. This 259 format is further restricted to enforce a minimum value of one. 261 If a maxSigLife is not provided by the client or if the server does 262 not support the client specified maxSigLife, the default signature 263 expiration policy of the server operator (as determined using an out- 264 of-band mechanism) applies. 266 4. DS Data Interface and Key Data Interface 268 This document describes operational scenarios in which a client can 269 create, add, and remove delegation signer (DS) information or key 270 data information for a domain name. There are two different forms of 271 interfaces that a server can support. The first is called the "DS 272 Data Interface," where the client is responsible for the creation of 273 the DS information and is required to pass DS information when 274 performing adds and removes. The server is required to pass DS 275 information for responses. The second is the "Key Data 276 Interface," where the client is responsible for passing the key data 277 information when performing adds and removes. The server is 278 responsible to pass key data information for responses. 280 The server MUST support one form of interface within a single command 281 or response, where and MUST NOT be 282 mixed except for when is a child element of for server validation. The server MUST support the use of 284 only one form of interface across all , , and elements except during a transition 286 period during which time the server MAY support both. For instance, 287 during a transition period the server MAY support either the DS Data 288 Interface or the Key Data Interface on a per domain basis and allow 289 the client to migrate to the target interface. The client can 290 replace the interface used by utilizing the true element to remove all data of the 292 old interface and utilizing the to add data using the 293 new interface ( for the DS Data Interface and for the Key Data Interface). The server MUST return an EPP 295 error result code of 2306 if the server receives a command using an 296 unsupported interface. 298 4.1. DS Data Interface 300 The DS Data Interface relies on the use of the 301 element for creates, adds, removes, and responses. The 302 key data associated with the DS information MAY be provided by the 303 client, but the server is not obligated to use the key data. The 304 server operator MAY also issue out-of-band DNS queries to retrieve 305 the key data from the registered domain's apex in order to evaluate 306 the received DS information. It is RECOMMENDED that the child zone 307 operator have this key data online in the DNS tree to allow the 308 parent zone administrator to validate the data as necessary. The key 309 data SHOULD have the Secure Entry Point (SEP) bit set as described in 310 RFC 3757 [RFC3757]. 312 The element contains the following child elements: 314 - A element that contains a key tag value as 315 described in section 5.1.1 of RFC 4034 [RFC4034]. The element is represented as an unsignedShort 317 [W3C.REC-xmlschema-2-20010502]. 319 - A element that contains an algorithm value as 320 described in section 5.1.2 of RFC 4034 [RFC4034]. 322 - A element that contains a digest type value as 323 described in section 5.1.3 of RFC 4034 [RFC4034]. 325 - A element that contains a digest value as 326 described in section 5.1.4 of RFC 4034 [RFC4034]. The element is represented as a hexBinary 328 [W3C.REC-xmlschema-2-20010502]. 330 - An OPTIONAL element that describes the key data 331 used as input in the DS hash calculation for use in server 332 validation. The element contains the child 333 elements defined in Section 4.2. 335 4.2. Key Data Interface 337 The Key Data Interface relies on the use of the 338 element for creates, adds, removes, and responses. The 339 DS information is not provided by the client but is generated by the 340 server. The attributes used for DS generation is based on server 341 policy, where only key data is passed between the client and the 342 server. 344 The element contains the following child elements: 346 - A element that contains a flags field value as 347 described in section 2.1.1 of RFC 4034 [RFC4034]. 349 - A element that contains a protocol field value 350 as described in section 2.1.2 of RFC 4034 [RFC4034]. 352 - A element that contains an algorithm number field 353 value as described in sections 2.1.3 of RFC 4034 [RFC4034]. 355 - A element that contains an encoded public key 356 field value as described in sections 2.1.4 of RFC 4034 [RFC4034]. 357 The element is represented as a base64Binary 358 [W3C.REC-xmlschema-2-20010502] with a minimum length of 1. 360 4.3. Example DS Data Interface and Key Data Interface 362 Example use of the secDNS-1.1 DS Data Interface for a create: 364 365 12345 366 3 367 1 368 49FD46E6C4B45C55D4AC 369 371 Example use of secDNS-1.1 DS Data Interface with option key data for 372 a create: 374 375 12345 376 3 377 1 378 49FD46E6C4B45C55D4AC 379 380 256 381 3 382 1 383 AQPJ////4Q== 384 385 387 Example use of the secDNS-1.1 Key Data Interface for a create: 389 390 256 391 3 392 1 393 AQPJ////4Q== 394 396 5. EPP Command Mapping 398 A detailed description of the EPP syntax and semantics can be found 399 in the EPP core protocol specification [RFC5730]. The command 400 mappings described here are specifically for use in provisioning and 401 managing DNS security extensions via EPP. 403 5.1. EPP Query Commands 405 EPP provides three commands to retrieve object information: 406 to determine if an object is known to the server, to retrieve 407 detailed information associated with an object, and to 408 retrieve object transfer status information. 410 5.1.1. EPP Command 412 This extension does not add any elements to the EPP command 413 or response described in the EPP domain mapping [RFC5731]. 415 5.1.2. EPP Command 417 This extension does not add any elements to the EPP command 418 described in the EPP domain mapping [RFC5731]. However, additional 419 elements are defined for the response. 421 When an command has been processed successfully, the EPP 422 element MUST contain child elements as described in the EPP 423 domain mapping [RFC5731]. In addition, the EPP element 424 SHOULD contain a child element that identifies the 425 extension namespace if the domain object has data associated with 426 this extension and based on server policy. The 427 element contains the following child elements: 429 - An OPTIONAL element that indicates a child's 430 preference for the number of seconds after signature generation 431 when the parent's signature on the DS information provided by the 432 child will expire. The maxSigLife is described in Section 3.3. 434 - One or more elements or elements, 435 but not both as defined in Section 4. The 436 elements describe the delegation signer (DS) data provided by the 437 client for the domain. The elements that 438 describe the key data provided by the client for the domain. 439 Child elements of the element are described in 440 Section 4.1. Child elements of the are described 441 in Section 4.2. 443 Example Response for a Secure Delegation 444 using the DS Data Interface: 446 S: 447 S: 449 S: 450 S: 451 S: Command completed successfully 452 S: 453 S: 454 S: 456 S: example.com 457 S: EXAMPLE1-REP 458 S: 459 S: jd1234 460 S: sh8013 461 S: sh8013 462 S: 463 S: ns1.example.com 464 S: ns2.example.com 465 S: 466 S: ns1.example.com 467 S: ns2.example.com 468 S: ClientX 469 S: ClientY 470 S: 1999-04-03T22:00:00.0Z 471 S: ClientX 472 S: 1999-12-03T09:00:00.0Z 473 S: 2005-04-03T22:00:00.0Z 474 S: 2000-04-08T09:00:00.0Z 475 S: 476 S: 2fooBAR 477 S: 478 S: 479 S: 480 S: 481 S: 483 S: 484 S: 12345 485 S: 3 486 S: 1 487 S: 49FD46E6C4B45C55D4AC 488 S: 489 S: 490 S: 491 S: 492 S: ABC-12345 493 S: 54322-XYZ 494 S: 495 S: 496 S: 498 Example Response for a Secure Delegation 499 using the DS Data Interface with OPTIONAL Key Data: 501 S: 502 S: 504 S: 505 S: 506 S: Command completed successfully 507 S: 508 S: 509 S: 511 S: example.com 512 S: EXAMPLE1-REP 513 S: 514 S: jd1234 515 S: sh8013 516 S: sh8013 517 S: 518 S: ns1.example.com 519 S: ns2.example.com 520 S: 521 S: ns1.example.com 522 S: ns2.example.com 523 S: ClientX 524 S: ClientY 525 S: 1999-04-03T22:00:00.0Z 526 S: ClientX 527 S: 1999-12-03T09:00:00.0Z 528 S: 2005-04-03T22:00:00.0Z 529 S: 2000-04-08T09:00:00.0Z 530 S: 531 S: 2fooBAR 532 S: 533 S: 534 S: 535 S: 536 S: 538 S: 604800 539 S: 540 S: 12345 541 S: 3 542 S: 1 543 S: 49FD46E6C4B45C55D4AC 544 S: 545 S: 256 546 S: 3 547 S: 1 548 S: AQPJ////4Q== 549 S: 550 S: 551 S: 552 S: 553 S: 554 S: ABC-12345 555 S: 54322-XYZ 556 S: 557 S: 558 S: 560 Example Response for a Secure Delegation 561 using the Key Data Interface: 563 S: 564 S: 566 S: 567 S: 568 S: Command completed successfully 569 S: 570 S: 571 S: 573 S: example.com 574 S: EXAMPLE1-REP 575 S: 576 S: jd1234 577 S: sh8013 578 S: sh8013 579 S: 580 S: ns1.example.com 581 S: ns2.example.com 582 S: 583 S: ns1.example.com 584 S: ns2.example.com 585 S: ClientX 586 S: ClientY 587 S: 1999-04-03T22:00:00.0Z 588 S: ClientX 589 S: 1999-12-03T09:00:00.0Z 590 S: 2005-04-03T22:00:00.0Z 591 S: 2000-04-08T09:00:00.0Z 592 S: 593 S: 2fooBAR 594 S: 595 S: 596 S: 597 S: 598 S: 600 S: 601 S: 256 602 S: 3 603 S: 1 604 S: AQPJ////4Q== 605 S: 606 S: 607 S: 608 S: 609 S: ABC-12345 610 S: 54322-XYZ 611 S: 612 S: 613 S: 615 An EPP error response MUST be returned if an command can not 616 be processed for any reason. 618 5.1.3. EPP Command 620 This extension does not add any elements to the EPP 621 command or response described in the EPP domain mapping 622 [RFC5731]. 624 5.2. EPP Transform Commands 626 EPP provides five commands to transform objects: to create 627 an instance of an object, to delete an instance of an 628 object, to extend the validity period of an object, 629 to manage object sponsorship changes, and to 630 change information associated with an object. 632 5.2.1. EPP Command 634 This extension defines additional elements for the EPP 635 command described in the EPP domain mapping [RFC5731]. No additional 636 elements are defined for the EPP response. 638 The EPP command provides a transform operation that allows a 639 client to create a domain object. In addition to the EPP command 640 elements described in the EPP domain mapping [RFC5731], the command 641 MUST contain an element and the element MUST 642 contain a child element that identifies the extension 643 namespace if the client wants to associate data defined in this 644 extension to the domain object. The element contains 645 the following child elements: 647 - An OPTIONAL element that indicates a child's 648 preference for the number of seconds after signature generation 649 when the parent's signature on the DS information provided by the 650 child will expire. The maxSigLife is described in Section 3.3. 651 If the server does not support the element a 652 2102 error MUST be returned. 654 - Zero or more elements or 655 elements, but not both as defined in Section 4. Child elements of 656 the element are described in Section 4.1. Child 657 elements of the are described in Section 4.2. 659 Example Command for a Secure Delegation 660 using the DS Data Interface: 662 C: 663 C: 665 C: 666 C: 667 C: 669 C: example.com 670 C: 2 671 C: 672 C: ns1.example.com 673 C: ns2.example.com 674 C: 675 C: jd1234 676 C: sh8013 677 C: sh8013 678 C: 679 C: 2fooBAR 680 C: 681 C: 682 C: 683 C: 684 C: 686 C: 604800 687 C: 688 C: 12345 689 C: 3 690 C: 1 691 C: 49FD46E6C4B45C55D4AC 692 C: 693 C: 694 C: 695 C: ABC-12345 696 C: 697 C: 698 Example Command for a Secure Delegation 699 using the DS Data Interface with OPTIONAL key data: 701 C: 702 C: 704 C: 705 C: 706 C: 708 C: example.com 709 C: 2 710 C: 711 C: ns1.example.com 712 C: ns2.example.com 713 C: 714 C: jd1234 715 C: sh8013 716 C: sh8013 717 C: 718 C: 2fooBAR 719 C: 720 C: 721 C: 722 C: 723 C: 725 C: 604800 726 C: 727 C: 12345 728 C: 3 729 C: 1 730 C: 49FD46E6C4B45C55D4AC 731 C: 732 C: 256 733 C: 3 734 C: 1 735 C: AQPJ////4Q== 736 C: 737 C: 738 C: 739 C: 740 C: ABC-12345 741 C: 742 C: 743 Example Command for a Secure Delegation 744 using the Key Data Interface: 746 C: 747 C: 749 C: 750 C: 751 C: 753 C: example.com 754 C: 2 755 C: 756 C: ns1.example.com 757 C: ns2.example.com 758 C: 759 C: jd1234 760 C: sh8013 761 C: sh8013 762 C: 763 C: 2fooBAR 764 C: 765 C: 766 C: 767 C: 768 C: 770 C: 771 C: 256 772 C: 3 773 C: 1 774 C: AQPJ////4Q== 775 C: 776 C: 777 C: 778 C: ABC-12345 779 C: 780 C: 782 When a command has been processed successfully, the EPP 783 response is as described in the EPP domain mapping [RFC5731]. 785 5.2.2. EPP Command 787 This extension does not add any elements to the EPP command 788 or response described in the EPP domain mapping [RFC5731]. 790 5.2.3. EPP Command 792 This extension does not add any elements to the EPP command 793 or response described in the EPP domain mapping [RFC5731]. 795 5.2.4. EPP Command 797 This extension does not add any elements to the EPP 798 command or response described in the EPP domain mapping 799 [RFC5731]. 801 5.2.5. EPP Command 803 This extension defines additional elements for the EPP 804 command described in the EPP domain mapping [RFC5731]. No additional 805 elements are defined for the EPP response. 807 The EPP command provides a transform operation that allows a 808 client to modify the attributes of a domain object. In addition to 809 the EPP command elements described in the EPP domain mapping, the 810 command MUST contain an element and the 811 element MUST contain a child element that identifies 812 the extension namespace if the client wants to update the domain 813 object with data defined in this extension. The 814 element contains a element to add security information 815 to a delegation, a element to remove security 816 information from a delegation, or a element to change 817 existing security information. At least one , , or element MUST be provided. The order of the 819 and is significant, where the server MUST 820 first remove the existing elements prior to adding the new elements. 822 The element also contains an OPTIONAL "urgent" 823 attribute that a client can use to ask the server operator to 824 complete and implement the update request with high priority. This 825 attribute accepts boolean values as described in Section 3.2; the 826 default value is boolean false. "High priority" is relative to 827 standard server operator policies that are determined using an out- 828 of-band mechanism. A server MUST return an EPP error result code of 829 2102 if the "urgent" attribute is specified and the server does not 830 support it. A server MUST return an EPP error result code of 2306 if 831 the server supports the "urgent" attribute and an urgent update 832 (noted with an "urgent" attribute value of boolean true) can not be 833 completed with high priority. 835 The element contains the following child elements: 837 - An OPTIONAL element that contains a 838 element or one or more or 839 elements that are used to remove security data from a delegation. 841 The element is used to remove all DS and key data 842 with a value of boolean true. A value of boolean false will do 843 nothing. Removing all DS information can remove the ability of 844 the parent to secure the delegation to the child zone. 846 The element is part of the DS Data Interface and 847 is used to uniquely define the DS record to remove by using all 848 four elements , , , 849 and that is guaranteed to be unique. 851 The element is part of the Key Data Interface and 852 is used to uniquely define the key data to remove by using all 853 four elements , , , and 854 that is guaranteed to be unique. There can be 855 more than one DS record created for each key, so removing a key 856 could remove more than one DS record. 858 - An OPTIONAL element that is used to add security 859 information to an existing set. The element MUST 860 contain one or more or elements. 861 Child elements of the element are described in 862 Section 4.1. Child elements of the are described 863 in Section 4.2. 865 - An OPTIONAL element that contains security 866 information to be changed. A elements contains the 867 following child elements: 869 - An OPTIONAL element that indicates a 870 child's preference for the number of seconds after signature 871 generation when the parent's signature on the DS information 872 provided by the child will expire. The maxSigLife is described 873 in Section 3.3. If the server does not support the element a 2102 error MUST be returned. 876 Example Command, Adding and Removing DS 877 Data using the DS Data Interface: 879 C: 880 C: 882 C: 883 C: 884 C: 886 C: example.com 887 C: 888 C: 889 C: 890 C: 892 C: 893 C: 894 C: 12345 895 C: 3 896 C: 1 897 C: 38EC35D5B3A34B33C99B 898 C: 899 C: 900 C: 901 C: 902 C: 12346 903 C: 3 904 C: 1 905 C: 38EC35D5B3A34B44C39B 906 C: 907 C: 908 C: 909 C: 910 C: ABC-12345 911 C: 912 C: 913 Example Command, 914 Update the maxSigLife: 916 C: 917 C: 919 C: 920 C: 921 C: 923 C: example.com 924 C: 925 C: 926 C: 927 C: 929 C: 930 C: 605900 931 C: 932 C: 933 C: 934 C: ABC-12345 935 C: 936 C: 937 Example Command, Adding and Removing Key 938 Data using the Key Data Interface and set maxSigLife: 940 C: 941 C: 943 C: 944 C: 945 C: 947 C: example.com 948 C: 949 C: 950 C: 951 C: 953 C: 954 C: 955 C: 256 956 C: 3 957 C: 1 958 C: AQPJ////4QQQ 959 C: 960 C: 961 C: 962 C: 963 C: 256 964 C: 3 965 C: 1 966 C: AQPJ////4Q== 967 C: 968 C: 969 C: 970 C: 605900 971 C: 972 C: 973 C: 974 C: ABC-12345 975 C: 976 C: 977 Example Command, Removing DS Data with 978 using the DS Data Interface: 980 C: 981 C: 983 C: 984 C: 985 C: 987 C: example.com 988 C: 989 C: 990 C: 991 C: 993 C: 994 C: 995 C: 12346 996 C: 3 997 C: 1 998 C: 38EC35D5B3A34B44C39B 999 C: 1000 C: 1001 C: 1002 C: 1003 C: ABC-12345 1004 C: 1005 C: 1006 Example Command, 1007 Removing all DS and Key Data using 1008 with : 1010 C: 1011 C: 1013 C: 1014 C: 1015 C: 1017 C: example.com 1018 C: 1019 C: 1020 C: 1021 C: 1023 C: 1024 C: true 1025 C: 1026 C: 1027 C: 1028 C: ABC-12345 1029 C: 1030 C: 1031 Example Urgent Command, 1032 Replacing all DS Data using the DS Data Interface: 1034 C: 1035 C: 1037 C: 1038 C: 1039 C: 1041 C: example.com 1042 C: 1043 C: 1044 C: 1045 C: 1047 C: 1048 C: true 1049 C: 1050 C: 1051 C: 1052 C: 12346 1053 C: 3 1054 C: 1 1055 C: 38EC35D5B3A34B44C39B 1056 C: 1057 C: 1058 C: 1059 C: 1060 C: ABC-12345 1061 C: 1062 C: 1064 When an extended command has been processed successfully, 1065 the EPP response is as described in the EPP domain mapping [RFC5731]. 1067 6. Formal Syntax 1069 An EPP object mapping is specified in XML Schema notation. The 1070 formal syntax presented here is a complete schema representation of 1071 the object mapping suitable for automated validation of EPP XML 1072 instances. The BEGIN and END tags are not part of the schema; they 1073 are used to note the beginning and ending of the schema for URI 1074 registration purposes. 1076 Copyright (c) 2009 IETF Trust and the persons identified as authors 1077 of the code. All rights reserved. 1079 Redistribution and use in source and binary forms, with or without 1080 modification, are permitted provided that the following conditions 1081 are met: 1083 o Redistributions of source code must retain the above copyright 1084 notice, this list of conditions and the following disclaimer. 1085 o Redistributions in binary form must reproduce the above copyright 1086 notice, this list of conditions and the following disclaimer in 1087 the documentation and/or other materials provided with the 1088 distribution. 1089 o Neither the name of Internet Society, IETF or IETF Trust, nor the 1090 names of specific contributors, may be used to endorse or promote 1091 products derived from this software without specific prior written 1092 permission. 1094 THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS 1095 "AS IS" AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT 1096 LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR 1097 A PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT 1098 OWNER OR CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, 1099 SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT 1100 LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, 1101 DATA, OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY 1102 THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT 1103 (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE 1104 OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE. 1106 BEGIN 1107 1108 1114 1115 1116 Extensible Provisioning Protocol v1.0 1117 domain name extension schema 1118 for provisioning DNS security (DNSSEC) extensions. 1119 1120 1122 1125 1126 1128 1132 1133 1134 1136 1137 1139 1141 1142 1143 1145 1148 1149 1150 1151 1152 1154 1157 1158 1159 1160 1161 1162 1163 1165 1166 1168 1172 1173 1174 1175 1176 1177 1178 1179 1181 1184 1185 1186 1187 1188 1190 1193 1194 1195 1197 1199 1201 1202 1203 1205 1208 1209 1210 1211 1213 1215 1217 1219 1222 1223 1224 1226 1227 1229 1232 1234 1235 END 1237 7. Internationalization Considerations 1239 EPP is represented in XML, which provides native support for encoding 1240 information using the Unicode character set and its more compact 1241 representations including UTF-8 [RFC3629]. Conformant XML processors 1242 recognize both UTF-8 and UTF-16 [RFC2781]. Though XML includes 1243 provisions to identify and use other character encodings through use 1244 of an "encoding" attribute in an declaration, use of UTF-8 is 1245 RECOMMENDED in environments where parser encoding support 1246 incompatibility exists. 1248 As an extension of the EPP domain mapping [RFC5731], the 1249 internationalization requirements in the EPP domain mapping [RFC5731] 1250 are followed by this extension. This extension does not override any 1251 of the EPP domain mapping [RFC5731] internationalization features. 1253 8. IANA Considerations 1255 This document uses URNs to describe XML namespaces and XML schemas 1256 conforming to a registry mechanism described in RFC 3688 [RFC3688]. 1257 Two URI assignments must be completed by the IANA. 1259 Registration request for the extension namespace: 1261 URI: urn:ietf:params:xml:ns:secDNS-1.1 1262 Registrant Contact: IESG 1264 XML: None. Namespace URIs do not represent an XML specification. 1266 Registration request for the extension XML schema: 1268 URI: urn:ietf:params:xml:schema:secDNS-1.1 1270 Registrant Contact: IESG 1272 XML: See the "Formal Syntax" section of this document. 1274 9. Security Considerations 1276 The mapping extensions described in this document do not provide any 1277 security services beyond those described by EPP [RFC5730], the EPP 1278 domain name mapping [RFC5731], and protocol layers used by EPP. The 1279 security considerations described in these other specifications apply 1280 to this specification as well. 1282 As with other domain object transforms, the EPP transform operations 1283 described in this document MUST be restricted to the sponsoring 1284 client as authenticated using the mechanisms described in sections 1285 2.9.1.1 and 7 of RFC 5730 [RFC5730]. Any attempt to perform a 1286 transform operation on a domain object by any client other than the 1287 sponsoring client MUST be rejected with an appropriate EPP 1288 authorization error. 1290 The provisioning service described in this document involves the 1291 exchange of information that can have an operational impact on the 1292 DNS. A trust relationship MUST exist between the EPP client and 1293 server, and provisioning of public key information MUST only be done 1294 after the identities of both parties have been confirmed using a 1295 strong authentication mechanism. 1297 An EPP client might be acting as an agent for a zone administrator 1298 who wants to send delegation information to be signed and published 1299 by the server operator. Man-in-the-middle attacks are thus possible 1300 as a result of direct client activity or inadvertent client data 1301 manipulation. 1303 Acceptance of a false key by a server operator can produce 1304 significant operational consequences. The child and parent zones 1305 MUST be consistent to secure the delegation properly. In the absence 1306 of consistent signatures, the delegation will not appear in the 1307 secure name space, yielding untrustworthy query responses. If a key 1308 is compromised, a client can either remove the compromised 1309 information or update the delegation information via EPP commands 1310 using the "urgent" attribute. 1312 Operational scenarios requiring quick removal of a secure domain 1313 delegation can be implemented using a two-step process. First, 1314 security credentials can be removed using an "urgent" update as just 1315 described. The domain can then be removed from the parent zone by 1316 changing the status of the domain to either of the EPP "clientHold" 1317 or "serverHold" domain status values. The domain can also be removed 1318 from the zone using the EPP command, but this is a more 1319 drastic step that needs to be considered carefully before use. 1321 Data validity checking and Delegation Signer record creation at the 1322 server requires computational resources. A purposeful or inadvertent 1323 denial-of-service attack is possible if a client requests some number 1324 of update operations that exceed a server's processing capabilities. 1325 Server operators SHOULD take steps to manage command load and command 1326 processing requirements to minimize the risk of a denial-of-service 1327 attack. 1329 The signature lifetime values provided by clients are requests that 1330 can be rejected. Blind acceptance by a server operator can have an 1331 adverse impact on a server's processing capabilities. Server 1332 operators SHOULD seriously consider adopting implementation rules to 1333 limit the range of acceptable signature lifetime values to counter 1334 potential adverse situations. 1336 10. Acknowledgements 1338 The author would like to thank the following people who have provided 1339 significant contributions to the development of this document: 1341 David Blacka, Howard Eland, Patrik Faltstrom, Olafur Gudmundsson, 1342 Bernie Hoeneisen, Ed Lewis, Klaus Malorny, Alexander Mayrhofer, 1343 Patrick Mevzek, David Smith, Andrew Sullivan, Srikanth 1344 Veeramachaneni. 1346 This document is an update of RFC 4310 [RFC4310]. Please see the 1347 Acknowledgements section in that RFC for additional acknowledgements. 1349 11. References 1351 11.1. Normative References 1353 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1354 Requirement Levels", BCP 14, RFC 2119, March 1997. 1356 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1357 January 2004. 1359 [RFC3757] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name 1360 System KEY (DNSKEY) Resource Record (RR) Secure Entry 1361 Point (SEP) Flag", RFC 3757, April 2004. 1363 [RFC4034] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1364 Rose, "Resource Records for the DNS Security Extensions", 1365 RFC 4034, March 2005. 1367 [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1368 Rose, "Protocol Modifications for the DNS Security 1369 Extensions", RFC 4035, March 2005. 1371 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1372 STD 69, RFC 5730, August 2009. 1374 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1375 Domain Name Mapping", STD 69, RFC 5731, August 2009. 1377 [W3C.REC-xml-20001006] 1378 Bray, T., Sperberg-McQueen, C., Paoli, J., and E. Maler, 1379 "Extensible Markup Language (XML) 1.0 (Second Edition)", 1380 World Wide Web Consortium FirstEdition REC-xml-20001006, 1381 October 2000, 1382 . 1384 [W3C.REC-xmlschema-1-20010502] 1385 Mendelsohn, N., Thompson, H., Maloney, M., and D. Beech, 1386 "XML Schema Part 1: Structures", World Wide Web Consortium 1387 FirstEdition REC-xmlschema-1-20010502, May 2001, 1388 . 1390 [W3C.REC-xmlschema-2-20010502] 1391 Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes", 1392 World Wide Web Consortium FirstEdition REC-xmlschema-2- 1393 20010502, May 2001, 1394 . 1396 11.2. Informative References 1398 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1399 STD 13, RFC 1034, November 1987. 1401 [RFC1035] Mockapetris, P., "Domain names - implementation and 1402 specification", STD 13, RFC 1035, November 1987. 1404 [RFC2781] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 1405 10646", RFC 2781, February 2000. 1407 [RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO 1408 10646", STD 63, RFC 3629, November 2003. 1410 [RFC4033] Arends, R., Austein, R., Larson, M., Massey, D., and S. 1411 Rose, "DNS Security Introduction and Requirements", 1412 RFC 4033, March 2005. 1414 [RFC4310] Hollenbeck, S., "Domain Name System (DNS) Security 1415 Extensions Mapping for the Extensible Provisioning 1416 Protocol (EPP)", RFC 4310, December 2005. 1418 Appendix A. Changes from RFC 4310 1420 1. Added the motivation in obsoleting RFC 4310 [RFC4310] to 1421 Section 1. 1422 2. Updated Section 1 to add an explicit statement about deprecation 1423 of RFC 4310. 1424 3. Added secDNS-1.0 and secDNS-1.1 abbreviation definitions in 1425 Section 1.1. 1426 4. Updated "Data validity checking at the server..." to "Data 1427 validity checking and Delegation Signer record creation at the 1428 server..." in Section 9. 1429 5. Added Section 2. 1430 6. Updated the second paragraph of Section 7 to clarify that the 1431 internationalization features of [RFC5731] are followed. 1432 7. Moved prior to to conform to the EPP 1433 order semantics for supporting with to 1434 remove all data and supporting the replace semantics previously 1435 supported by . 1436 8. Added support for the use of boolean element under 1437 to remove all DS or key data in place of using 1438 . 1439 9. Updated , , and to function 1440 in a consistent way to the other EPP RFC's. 1441 10. Removed support for using just . 1442 11. Moved the element out of the 1443 and elements and directly under the element, under the element of the element, and under the element. 1446 Section 3.3 was updated to better describe the element and references to the 1448 element were updated throughout the document. 1449 12. Replaced references of urn:ietf:params:xml:schema:secDNS-1.0 to 1450 urn:ietf:params:xml:schema:secDNS-1.1 and replaced "Two URI 1451 assignments have been completed by the IANA." with "Two URI 1452 assignments must be completed by the IANA." in Section 8. 1453 13. Changed "Added clarify on ..." in Appendix A to "Added 1454 clarification on ...". 1455 14. Changed all references of "more then" to "more than". 1456 15. Changed "The DS Data Interface relies uses the ..." in 1457 Section 4.1 to "The DS Data Interface relies on the ...". 1458 16. Added "The element is represented as an 1459 unsignedShort [W3C.REC-xmlschema-2-20010502]" in Section 4.1. 1460 17. Added "The element is represented as a hexBinary 1461 [W3C.REC-xmlschema-2-20010502]" in Section 4.1. 1462 18. Added "The element is represented as a 1463 base64Binary [W3C.REC-xmlschema-2-20010502] with a minimum 1464 length of 1." in Section 4.2. 1465 19. Combined the command MUST contain an element with 1466 the following sentence in Section 5.2.1 and Section 5.2.5. 1467 20. Added sentence "If the server does not support updating the 1468 the server MUST return an EPP error result 1469 code of 2102." to Section 5.2.5 and Section 5.2.1. 1470 21. Added sentence "This document is an update of RFC 4310. Please 1471 see the Acknowledgements section in that RFC for additional 1472 acknowledgements." in Section 10. 1473 22. Added "This document incorporates feedback from implementers on 1474 the PROVREG mail list and users." as well as "This document 1475 obsoletes RFC 4310" in the Abstract 1476 23. Removed all references to xsi:schemaLocation to be consistent 1477 with the other EPP RFCs. 1478 24. Added "DS Data Interface and Key Data Interface" section. 1479 25. Moved the "create, add, remove, and replace delegation signer 1480 (DS) information" paragraph from the "Object Attributes" section 1481 to the "DS Data Interface" section. 1482 26. Replaced the element descriptions in the "EPP Command" 1483 section with a reference to the and elements described in the "DS Data Interface" and "Key 1485 Data Interface" sections, respectively. 1486 27. Updated the "EPP Command" section examples to include 1487 both the DS Data Interface and the Key Data Interface. 1488 28. Updated the "EPP Command" section to refer to both the 1489 use of and described in the "DS 1490 Data Interface" and "Key Data Interface" sections, respectively. 1491 29. Updated the "EPP Command" section examples to include 1492 both the DS Data Interface and the Key Data Interface. 1493 30. Updated the "EPP Command" section to describe the use 1494 of , , and together. 1495 31. Updated the "EPP Command" section examples to include 1496 both the DS Data Interface and the Key Data Interface. Also 1497 included additional examples of adding and removing DS data or 1498 key data. 1500 32. Updated the "Formal Syntax" section with the updated XML schema. 1501 33. Updated the Acknowledgements section with a new list of 1502 contributors. 1503 34. Replaced references to RFC 3730 with references to RFC 5730. 1504 35. Replaced references to RFC 3731 with references to RFC 5731. 1505 36. Added the references to the elements , , , and 1507 using the . 1508 37. Added clarification on when the extension MUST be included for 1509 each of the commands and responds (, , ). 1511 38. Changed "In addition, the EPP element MUST contain a 1512 child element" to "In addition, the EPP 1513 element SHOULD contain a child 1514 element" and added "and based on server policy". 1516 Authors' Addresses 1518 James Gould 1519 VeriSign, Inc. 1520 21345 Ridgetop Circle 1521 Dulles, VA 20166-6503 1522 US 1524 EMail: jgould@verisign.com 1526 Scott Hollenbeck 1527 VeriSign, Inc. 1528 21345 Ridgetop Circle 1529 Dulles, VA 20166-6503 1530 US 1532 EMail: shollenbeck@verisign.com