idnits 2.17.1 draft-hollenbeck-epp-secdns-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 1024. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1001. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1008. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1014. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard 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 RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 551 has weird spacing: '...ure the deleg...' -- 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 (August 8, 2005) is 6829 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 3730 (ref. '1') (Obsoleted by RFC 4930) ** Obsolete normative reference: RFC 3731 (ref. '2') (Obsoleted by RFC 4931) -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' -- Possible downref: Non-RFC (?) normative reference: ref. '5' ** Obsolete normative reference: RFC 3757 (ref. '9') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) Summary: 6 errors (**), 0 flaws (~~), 4 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group S. Hollenbeck 3 Internet-Draft VeriSign, Inc. 4 Expires: February 9, 2006 August 8, 2005 6 Domain Name System (DNS) Security Extensions Mapping for the 7 Extensible Provisioning Protocol (EPP) 8 draft-hollenbeck-epp-secdns-08.txt 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on February 9, 2006. 35 Copyright Notice 37 Copyright (C) The Internet Society (2005). 39 Abstract 41 This document describes an Extensible Provisioning Protocol (EPP) 42 extension mapping for the provisioning and management of Domain Name 43 System security extensions (DNSSEC) for domain names stored in a 44 shared central repository. Specified in XML, this mapping extends 45 the EPP domain name mapping to provide additional features required 46 for the provisioning of DNS security extensions. 48 Table of Contents 50 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 1.1 Conventions Used In This Document . . . . . . . . . . . . 3 52 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 53 2.1 Delegation Signer Information . . . . . . . . . . . . . . 4 54 2.1.1 Public Key Information . . . . . . . . . . . . . . . . 4 55 2.2 Booleans . . . . . . . . . . . . . . . . . . . . . . . . . 4 56 2.3 Maximum Signature Lifetime Values . . . . . . . . . . . . 4 57 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4 58 3.1 EPP Query Commands . . . . . . . . . . . . . . . . . . . . 5 59 3.1.1 EPP Command . . . . . . . . . . . . . . . . . 5 60 3.1.2 EPP Command . . . . . . . . . . . . . . . . . . 5 61 3.1.3 EPP Command . . . . . . . . . . . . . . . . 9 62 3.2 EPP Transform Commands . . . . . . . . . . . . . . . . . . 9 63 3.2.1 EPP Command . . . . . . . . . . . . . . . . . 9 64 3.2.2 EPP Command . . . . . . . . . . . . . . . . . 12 65 3.2.3 EPP Command . . . . . . . . . . . . . . . . . 12 66 3.2.4 EPP Command . . . . . . . . . . . . . . . . 12 67 3.2.5 EPP Command . . . . . . . . . . . . . . . . . 12 68 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 18 69 5. Internationalization Considerations . . . . . . . . . . . . . 20 70 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 71 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 72 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 73 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 74 9.1 Normative References . . . . . . . . . . . . . . . . . . . 22 75 9.2 Informative References . . . . . . . . . . . . . . . . . . 23 76 Author's Address . . . . . . . . . . . . . . . . . . . . . . . 23 77 Intellectual Property and Copyright Statements . . . . . . . . 24 79 1. Introduction 81 This document describes an extension mapping for version 1.0 of the 82 Extensible Provisioning Protocol (EPP) described in RFC 3730 [1]. 83 This mapping, an extension of the domain name mapping described in 84 RFC 3731 [2], is specified using the Extensible Markup Language (XML) 85 1.0 [3] and XML Schema notation ([4], [5]). 87 The EPP core protocol specification [1] provides a complete 88 description of EPP command and response structures. A thorough 89 understanding of the base protocol specification is necessary to 90 understand the mapping described in this document. Familiarity with 91 the Domain Name System (DNS) described in RFC 1034 [11] and RFC 1035 92 [12], and DNS security extensions described in RFC 4033 [13], RFC 93 4034 [6], and RFC 4035 [7] is required to understand the DNS security 94 concepts described in this document. 96 The EPP mapping described in this document specifies a mechanism for 97 the provisioning and management of DNS security extensions in a 98 shared central repository. Information exchanged via this mapping 99 can be extracted from the repository and used to publish DNSSEC 100 delegation signer (DS) resource records as described in RFC 4034 [6]. 102 1.1 Conventions Used In This Document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in BCP 14, RFC 2119 [8]. 108 In examples, "C:" represents lines sent by a protocol client and "S:" 109 represents lines returned by a protocol server. "////" is used to 110 note element values that have been shortened to better fit page 111 boundaries. Indentation and white space in examples is provided only 112 to illustrate element relationships and is not a mandatory feature of 113 this protocol. 115 XML is case sensitive. Unless stated otherwise, XML specifications 116 and examples provided in this document MUST be interpreted in the 117 character case presented to develop a conforming implementation. 119 2. Object Attributes 121 This extension adds additional elements to the EPP domain name 122 mapping [2]. Only new element descriptions are described here. 124 This document describes operational scenarios in which a client can 125 create delegation signer (DS) information, add delegation signer 126 information, remove delegation signer information, and replace 127 existing delegation signer information. Key data associated with the 128 DS information MAY be provided by the client, but the server is not 129 obligated to use the key data. The server operator MAY also issue 130 out-of-band DNS queries to retrieve the key data from the registered 131 domain's apex in order to evaluate the received DS information. It 132 is RECOMMENDED that the child zone operator have this key data online 133 in the DNS tree to allow the parent zone administrator to validate 134 the data as necessary and the key data SHOULD have the Secure Entry 135 Point (SEP) bit set as described in RFC 3757 [9]. 137 2.1 Delegation Signer Information 139 Delegation signer (DS) information is published by a DNS server to 140 indicate that a child zone is digitally signed and that the parent 141 zone recognizes the indicated key as a valid zone key for the child 142 zone. A DS RR contains four fields: a key tag field, a key algorithm 143 number octet, an octet identifying the digest algorithm used, and a 144 digest field. See RFC 4034 [6] for specific field formats. 146 2.1.1 Public Key Information 148 Public key information provided by a client maps to the DNSKEY RR 149 presentation field formats described in section 2.2 of RFC 4034 [6]. 150 A DNSKEY RR contains four fields: flags, a protocol octet, an 151 algorithm number octet, and a public key. 153 2.2 Booleans 155 Boolean values MUST be represented in the XML Schema format described 156 in Part 2 of the W3C XML Schema recommendation [5]. 158 2.3 Maximum Signature Lifetime Values 160 Maximum signature lifetime values MUST be represented in seconds 161 using an extended XML Schema "int" format. The base "int" format, 162 which allows negative numbers, is described in Part 2 of the W3C XML 163 Schema recommendation [5]. This format is further restricted to 164 enforce a minimum value of one. 166 3. EPP Command Mapping 168 A detailed description of the EPP syntax and semantics can be found 169 in the EPP core protocol specification [1]. The command mappings 170 described here are specifically for use in provisioning and managing 171 DNS security extensions via EPP. 173 3.1 EPP Query Commands 175 EPP provides three commands to retrieve object information: 176 to determine if an object is known to the server, to retrieve 177 detailed information associated with an object, and to 178 retrieve object transfer status information. 180 3.1.1 EPP Command 182 This extension does not add any elements to the EPP command 183 or response described in the EPP domain mapping [2]. 185 3.1.2 EPP Command 187 This extension does not add any elements to the EPP command 188 described in the EPP domain mapping [2]. Additional elements are 189 defined for the response. 191 When an command has been processed successfully, the EPP 192 element MUST contain child elements as described in the EPP 193 domain mapping [2]. In addition, the EPP element MUST 194 contain a child element that identifies the 195 extension namespace and the location of the extension schema. The 196 element contains the following child elements: 198 One or more elements that describe the delegation 199 signer data provided by the client for the domain. The element contains the following child elements: 202 A element that contains a key tag value as 203 described in section 5.1.1 of RFC 4034 [6]. 205 A element that contains an algorithm value as 206 described in section 5.1.2 of RFC 4034 [6]. 208 A element that contains a digest type value 209 as described in section 5.1.3 of RFC 4034 [6]. 211 A element that contains a digest value as 212 described in section 5.1.4 of RFC 4034 [6]. 214 An OPTIONAL element that indicates a 215 child's preference for the number of seconds after signature 216 generation when the parent's signature on the DS information 217 provided by the child will expire. If the 218 is not present, the default signature expiration policy of the 219 server operator (as determined using an out-of-band mechanism) 220 applies. 222 An OPTIONAL element that describes the key 223 data used as input in the DS hash calculation. The element contains the following child elements: 226 A element that contains a flags field value 227 as described in section 2.1.1 of RFC 4034 [6]. 229 A element that contains a protocol field 230 value as described in section 2.1.2 of RFC 4034 [6]. 232 A element that contains an algorithm number 233 field value as described in sections 2.1.3 of RFC 4034 [6]. 235 A element that contains an encoded public 236 key field value as described in sections 2.1.4 of RFC 4034 237 [6]. 239 Example Response for a Secure Delegation: 241 S: 242 S: 246 S: 247 S: 248 S: Command completed successfully 249 S: 250 S: 251 S: 255 S: example.com 256 S: EXAMPLE1-REP 257 S: 258 S: jd1234 259 S: sh8013 260 S: sh8013 261 S: 262 S: ns1.example.com 263 S: ns2.example.com 264 S: 265 S: ns1.example.com 266 S: ns2.example.com 267 S: ClientX 268 S: ClientY 269 S: 1999-04-03T22:00:00.0Z 270 S: ClientX 271 S: 1999-12-03T09:00:00.0Z 272 S: 2005-04-03T22:00:00.0Z 273 S: 2000-04-08T09:00:00.0Z 274 S: 275 S: 2fooBAR 276 S: 277 S: 278 S: 279 S: 280 S: 284 S: 285 S: 12345 286 S: 3 287 S: 1 288 S: 49FD46E6C4B45C55D4AC 289 S: 290 S: 291 S: 292 S: 293 S: ABC-12345 294 S: 54322-XYZ 295 S: 296 S: 297 S: 299 Example Response for a Secure Delegation with OPTIONAL Data: 301 S: 302 S: 306 S: 307 S: 308 S: Command completed successfully 309 S: 310 S: 311 S: 315 S: example.com 316 S: EXAMPLE1-REP 317 S: 318 S: jd1234 319 S: sh8013 320 S: sh8013 321 S: 322 S: ns1.example.com 323 S: ns2.example.com 324 S: 325 S: ns1.example.com 326 S: ns2.example.com 327 S: ClientX 328 S: ClientY 329 S: 1999-04-03T22:00:00.0Z 330 S: ClientX 331 S: 1999-12-03T09:00:00.0Z 332 S: 2005-04-03T22:00:00.0Z 333 S: 2000-04-08T09:00:00.0Z 334 S: 335 S: 2fooBAR 336 S: 337 S: 338 S: 339 S: 340 S: 344 S: 345 S: 12345 346 S: 3 347 S: 1 348 S: 49FD46E6C4B45C55D4AC 349 S: 604800 350 S: 351 S: 256 352 S: 3 353 S: 1 354 S: AQPJ////4Q== 355 S: 356 S: 357 S: 358 S: 359 S: 360 S: ABC-12345 361 S: 54322-XYZ 362 S: 363 S: 364 S: 366 An EPP error response MUST be returned if an command can not 367 be processed for any reason. 369 3.1.3 EPP Command 371 This extension does not add any elements to the EPP 372 command or response described in the EPP domain mapping 373 [2]. 375 3.2 EPP Transform Commands 377 EPP provides five commands to transform objects: to create 378 an instance of an object, to delete an instance of an 379 object, to extend the validity period of an object, 380 to manage object sponsorship changes, and to 381 change information associated with an object. 383 3.2.1 EPP Command 385 This extension defines additional elements for the EPP 386 command described in the EPP domain mapping [2]. An additional 387 element is also defined for the EPP response. 389 The EPP command provides a transform operation that allows a 390 client to create a domain object. In addition to the EPP command 391 elements described in the EPP domain mapping [2], the command MUST 392 contain an element. The element MUST contain 393 a child element that identifies the extension 394 namespace and the location of the extension schema. The element MUST contain one or more elements. 396 Child elements of the element are described in 397 Section 3.1.2. 399 The element contains OPTIONAL and 400 elements. The server MUST abort command processing 401 and respond with an appropriate EPP error if the values provided by 402 the client can not be accepted for syntax or policy reasons. 404 Example Command for a Secure Delegation: 406 C: 407 C: 411 C: 412 C: 413 C: 417 C: example.com 418 C: 2 419 C: 420 C: ns1.example.com 421 C: ns2.example.com 422 C: 423 C: jd1234 424 C: sh8013 425 C: sh8013 426 C: 427 C: 2fooBAR 428 C: 429 C: 430 C: 431 C: 432 C: 436 C: 437 C: 12345 438 C: 3 439 C: 1 440 C: 49FD46E6C4B45C55D4AC 441 C: 442 C: 443 C: 444 C: ABC-12345 445 C: 446 C: 448 Example Command for a Secure Delegation with OPTIONAL data: 450 C: 451 C: 455 C: 456 C: 457 C: 461 C: example.com 462 C: 2 463 C: 464 C: ns1.example.com 465 C: ns2.example.com 466 C: 467 C: jd1234 468 C: sh8013 469 C: sh8013 470 C: 471 C: 2fooBAR 472 C: 473 C: 474 C: 475 C: 476 C: 480 C: 481 C: 12345 482 C: 3 483 C: 1 484 C: 49FD46E6C4B45C55D4AC 485 C: 604800 486 C: 487 C: 256 488 C: 3 489 C: 1 490 C: AQPJ////4Q== 491 C: 492 C: 493 C: 494 C: 495 C: ABC-12345 496 C: 497 C: 498 When a command has been processed successfully, the EPP 499 response is as described in the EPP domain mapping [2]. 501 3.2.2 EPP Command 503 This extension does not add any elements to the EPP command 504 or response described in the EPP domain mapping [2]. 506 3.2.3 EPP Command 508 This extension does not add any elements to the EPP command 509 or response described in the EPP domain mapping [2]. 511 3.2.4 EPP Command 513 This extension does not add any elements to the EPP 514 command or response described in the EPP domain mapping 515 [2]. 517 3.2.5 EPP Command 519 This extension defines additional elements for the EPP 520 command described in the EPP domain mapping [2]. An additional 521 element is also defined for the EPP response. 523 The EPP command provides a transform operation that allows a 524 client to modify the attributes of a domain object. In addition to 525 the EPP command elements described in the EPP domain mapping, the 526 command MUST contain an element. The element 527 MUST contain a child element that identifies the 528 extension namespace and the location of the extension schema. The 529 element contains a element to add 530 security information to a delegation, a element to 531 remove security information from a delegation, or a 532 element to replace security information with new security 533 information. 535 The element also contains an OPTIONAL "urgent" 536 attribute that can be used by a client to ask the server operator to 537 complete and implement the update request with high priority. This 538 attribute accepts boolean values as described in Section 2.2; the 539 default value is boolean false. "High priority" is relative to 540 standard server operator policies that are determined using an out- 541 of-band mechanism. 543 The element is used to add DS information to an existing 544 set. The element MUST contain one or more elements as described in Section 3.1.2. 547 The element contains one or more 548 elements that are used to remove DS data from a delegation. The 549 element MUST contain a key tag value as described in 550 section 5.1.1 of RFC 4034 [6]. Removing all DS information can 551 remove the ability of the parent to secure the delegation to the 552 child zone. 554 The element is used to replace existing DS information 555 with new DS information. The element MUST contain one 556 or more elements as described in Section 3.1.2. The 557 data in these elements is used to replace whatever other data is 558 currently archived for the delegation. 560 The element contains an OPTIONAL "urgent" attribute. 561 In addition, the element contains OPTIONAL and elements. The server MUST abort 563 command processing and respond with an appropriate EPP error if the 564 values provided by the client can not be accepted for syntax or 565 policy reasons. 567 Example Command, Adding DS Data: 569 C: 570 C: 574 C: 575 C: 576 C: 580 C: example.com 581 C: 582 C: 583 C: 584 C: 588 C: 589 C: 590 C: 12346 591 C: 3 592 C: 1 593 C: 38EC35D5B3A34B44C39B 594 C: 595 C: 596 C: 597 C: 598 C: ABC-12345 599 C: 600 C: 601 Example Command, Removing DS Data: 603 C: 604 C: 608 C: 609 C: 610 C: 614 C: example.com 615 C: 616 C: 617 C: 618 C: 622 C: 623 C: 12345 624 C: 625 C: 626 C: 627 C: ABC-12345 628 C: 629 C: 630 Example Urgent Command, Changing DS Data: 632 C: 633 C: 637 C: 638 C: 639 C: 643 C: example.com 644 C: 645 C: 646 C: 647 C: 651 C: 652 C: 653 C: 12345 654 C: 3 655 C: 1 656 C: 49FD46E6C4B45C55D4AC 657 C: 658 C: 659 C: 660 C: 661 C: ABC-12345 662 C: 663 C: 664 Example Command, Changing Data to Include OPTIONAL Data: 666 C: 667 C: 671 C: 672 C: 673 C: 677 C: example.com 678 C: 679 C: 680 C: 681 C: 685 C: 686 C: 687 C: 12345 688 C: 3 689 C: 1 690 C: 49FD46E6C4B45C55D4AC 691 C: 604800 692 C: 693 C: 256 694 C: 3 695 C: 1 696 C: AQPJ////4Q== 697 C: 698 C: 699 C: 700 C: 701 C: 702 C: ABC-12345 703 C: 704 C: 706 When an extended command has been processed successfully, 707 the EPP response is as described in the EPP domain mapping [2]. A 708 server operator MUST return an EPP error result code of 2306 if an 709 urgent update (noted with an "urgent" attribute value of boolean 710 true) can not be completed with high priority. 712 4. Formal Syntax 714 An EPP object mapping is specified in XML Schema notation. The 715 formal syntax presented here is a complete schema representation of 716 the object mapping suitable for automated validation of EPP XML 717 instances. The BEGIN and END tags are not part of the schema; they 718 are used to note the beginning and ending of the schema for URI 719 registration purposes. 721 BEGIN 722 724 729 730 731 Extensible Provisioning Protocol v1.0 732 domain name extension schema for provisioning 733 DNS security (DNSSEC) extensions. 734 735 737 740 741 743 746 747 748 750 751 753 754 755 756 757 758 759 761 763 764 766 767 768 769 770 772 773 774 775 776 777 778 779 781 782 783 784 785 787 790 791 792 793 794 795 796 797 799 800 801 803 804 806 810 812 815 816 END 818 5. Internationalization Considerations 820 EPP is represented in XML, which provides native support for encoding 821 information using the Unicode character set and its more compact 822 representations including UTF-8 [14]. Conformant XML processors 823 recognize both UTF-8 and UTF-16 [15]. Though XML includes provisions 824 to identify and use other character encodings through use of an 825 "encoding" attribute in an declaration, use of UTF-8 is 826 RECOMMENDED in environments where parser encoding support 827 incompatibility exists. 829 As an extension of the EPP domain mapping [2], the elements, element 830 content, attributes, and attribute values described in this document 831 MUST inherit the internationalization conventions used to represent 832 higher-layer domain and core protocol structures present in an XML 833 instance that includes this extension. 835 6. IANA Considerations 837 This document uses URNs to describe XML namespaces and XML schemas 838 conforming to a registry mechanism described in RFC 3688 [10]. Two 839 URI assignments are requested. 841 Registration request for the extension namespace: 843 URI: urn:ietf:params:xml:ns:secDNS-1.0 845 Registrant Contact: IESG 847 XML: None. Namespace URIs do not represent an XML specification. 849 Registration request for the extension XML schema: 851 URI: urn:ietf:params:xml:schema:secDNS-1.0 853 Registrant Contact: IESG 855 XML: See the "Formal Syntax" section of this document. 857 7. Security Considerations 859 The mapping extensions described in this document do not provide any 860 security services beyond those described by EPP [1], the EPP domain 861 name mapping [2], and protocol layers used by EPP. The security 862 considerations described in these other specifications apply to this 863 specification as well. 865 As with other domain object transforms, the EPP transform operations 866 described in this document MUST be restricted to the sponsoring 867 client as authenticated using the mechanisms described in sections 868 2.9.1.1 and 7 of RFC 3730 [1]. Any attempt to perform a transform 869 operation on a domain object by any client other than the sponsoring 870 client MUST be rejected with an appropriate EPP authorization error. 872 The provisioning service described in this document involves the 873 exchange of information that can have an operational impact on the 874 DNS. A trust relationship MUST exist between the EPP client and 875 server, and provisioning of public key information MUST only be done 876 after the identities of both parties have been confirmed using a 877 strong authentication mechanism. 879 An EPP client might be acting as an agent for a zone administrator 880 who wants to send delegation information to be signed and published 881 by the server operator. Man-in-the-middle attacks are thus possible 882 as a result of direct client activity or inadvertent client data 883 manipulation. 885 Acceptance of a false key by a server operator can produce 886 significant operational consequences. The child and parent zones 887 MUST be consistent to properly secure the delegation. In the absence 888 of consistent signatures the delegation will not appear in the secure 889 name space, yielding untrustworthy query responses. If a key is 890 compromised, a client can either remove the compromised information 891 or update the delegation information via EPP commands using the 892 "urgent" attribute. 894 Operational scenarios requiring quick removal of a secure domain 895 delegation can be implemented using a two-step process. First, 896 security credentials can be removed using an "urgent" update as just 897 described. The domain can then be removed from the parent zone by 898 changing the status of the domain to either of the EPP "clientHold" 899 or "serverHold" domain status values. The domain can also be removed 900 from the zone using the EPP command, but this is a more 901 drastic step that needs to be considered carefully before use. 903 Data validity checking at the server requires computational 904 resources. A purposeful or inadvertent denial of service attack is 905 possible if a client requests some number of update operations that 906 exceed a server's processing capabilities. Server operators SHOULD 907 take steps to manage command load and command processing requirements 908 to minimize the risk of a denial of service attack. 910 The signature lifetime values provided by clients are requests that 911 can be rejected. Blind acceptance by a server operator can have an 912 adverse impact on a server's processing capabilities. Server 913 operators SHOULD seriously consider adopting implementation rules to 914 limit the range of acceptable signature lifetime values to counter 915 potential adverse situations. 917 8. Acknowledgements 919 The author would like to thank the following people who have provided 920 significant contributions to the development of this document: 922 David Blacka, Olafur Gudmundsson, Mark Kosters, Ed Lewis, Dan Massey, 923 Marcos Sanz, Sam Weiler, and Ning Zhang. 925 9. References 927 9.1 Normative References 929 [1] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 930 RFC 3730, March 2004. 932 [2] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) Domain 933 Name Mapping", RFC 3731, March 2004. 935 [3] Paoli, J., Sperberg-McQueen, C., Bray, T., and E. Maler, 936 "Extensible Markup Language (XML) 1.0 (Second Edition)", W3C 937 FirstEdition REC-xml-20001006, October 2000. 939 [4] Maloney, M., Beech, D., Mendelsohn, N., and H. Thompson, "XML 940 Schema Part 1: Structures", W3C REC REC-xmlschema-1-20010502, 941 May 2001. 943 [5] Malhotra, A. and P. Biron, "XML Schema Part 2: Datatypes", W3C 944 REC REC-xmlschema-2-20010502, May 2001. 946 [6] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 947 "Resource Records for the DNS Security Extensions", RFC 4034, 948 March 2005. 950 [7] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 951 "Protocol Modifications for the DNS Security Extensions", 952 RFC 4035, March 2005. 954 [8] Bradner, S., "Key words for use in RFCs to Indicate Requirement 955 Levels", BCP 14, RFC 2119, March 1997. 957 [9] Kolkman, O., Schlyter, J., and E. Lewis, "Domain Name System 958 KEY (DNSKEY) Resource Record (RR) Secure Entry Point (SEP) 959 Flag", RFC 3757, April 2004. 961 [10] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 962 January 2004. 964 9.2 Informative References 966 [11] Mockapetris, P., "Domain names - concepts and facilities", 967 STD 13, RFC 1034, November 1987. 969 [12] Mockapetris, P., "Domain names - implementation and 970 specification", STD 13, RFC 1035, November 1987. 972 [13] Arends, R., Austein, R., Larson, M., Massey, D., and S. Rose, 973 "DNS Security Introduction and Requirements", RFC 4033, 974 March 2005. 976 [14] Yergeau, F., "UTF-8, a transformation format of ISO 10646", 977 STD 63, RFC 3629, November 2003. 979 [15] Hoffman, P. and F. Yergeau, "UTF-16, an encoding of ISO 10646", 980 RFC 2781, February 2000. 982 Author's Address 984 Scott Hollenbeck 985 VeriSign, Inc. 986 21345 Ridgetop Circle 987 Dulles, VA 20166-6503 988 US 990 Email: shollenbeck@verisign.com 992 Intellectual Property Statement 994 The IETF takes no position regarding the validity or scope of any 995 Intellectual Property Rights or other rights that might be claimed to 996 pertain to the implementation or use of the technology described in 997 this document or the extent to which any license under such rights 998 might or might not be available; nor does it represent that it has 999 made any independent effort to identify any such rights. Information 1000 on the procedures with respect to rights in RFC documents can be 1001 found in BCP 78 and BCP 79. 1003 Copies of IPR disclosures made to the IETF Secretariat and any 1004 assurances of licenses to be made available, or the result of an 1005 attempt made to obtain a general license or permission for the use of 1006 such proprietary rights by implementers or users of this 1007 specification can be obtained from the IETF on-line IPR repository at 1008 http://www.ietf.org/ipr. 1010 The IETF invites any interested party to bring to its attention any 1011 copyrights, patents or patent applications, or other proprietary 1012 rights that may cover technology that may be required to implement 1013 this standard. Please address the information to the IETF at 1014 ietf-ipr@ietf.org. 1016 Disclaimer of Validity 1018 This document and the information contained herein are provided on an 1019 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1020 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 1021 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 1022 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 1023 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1024 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1026 Copyright Statement 1028 Copyright (C) The Internet Society (2005). This document is subject 1029 to the rights, licenses and restrictions contained in BCP 78, and 1030 except as set forth therein, the authors retain all their rights. 1032 Acknowledgment 1034 Funding for the RFC Editor function is currently provided by the 1035 Internet Society.