idnits 2.17.1 draft-wisser-registrylock-02.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 : ---------------------------------------------------------------------------- ** There are 15 instances of too long lines in the document, the longest one being 13 characters in excess of 72. ** The abstract seems to contain references ([RFC5731], [RFC5732], [RFC5733]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: With password authorization temporary unlock MUST not be implemented. Every command could be authorized by including the credentials in the command. -- The document date (April 7, 2020) is 1473 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) ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Registration Protocols Extensions U. Wisser 3 Internet-Draft The Swedish Internet Infrastructure Foundation 4 Intended status: Standards Track April 7, 2020 5 Expires: October 9, 2020 7 Registry Lock Extension for the Extensible Provisioning Protocol (EPP) 8 draft-wisser-registrylock-02 10 Abstract 12 This extensions defines an additional protective layer for changes to 13 domain [RFC5731], host [RFC5732] and contact [RFC5733] objects 14 managed through EPP. 16 EPP allows changes to objects only by the sponsoring client. EPP 17 objects are usually managed by the sponsoring client on behalf of the 18 sponsoring clients customers. All of these interactions are ususally 19 fully automated. 21 In case of a system breach, there is no protection in EPP to changes 22 to any object by the intruder. 24 This extension defines a protective layer that aims to break 25 automated changes and work flows by requiring manual intervention by 26 the sponsoring client or it's customers. 28 Status of This Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at https://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on October 9, 2020. 45 Copyright Notice 47 Copyright (c) 2020 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (https://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 63 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 64 2. Object Protection . . . . . . . . . . . . . . . . . . . . . . 3 65 2.1. Password Authorization . . . . . . . . . . . . . . . . . 4 66 2.2. Out-of-band Authorization . . . . . . . . . . . . . . . . 4 67 2.3. Command Execution Restrictions . . . . . . . . . . . . . 4 68 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 5 69 3.1. Locking Status . . . . . . . . . . . . . . . . . . . . . 5 70 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5 71 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 6 72 4.1.1. EPP Command . . . . . . . . . . . . . . . . . 6 73 4.1.2. EPP Command . . . . . . . . . . . . . . . . . 6 74 4.1.3. EPP Command . . . . . . . . . . . . . . . 9 75 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 9 76 4.2.1. EPP Command . . . . . . . . . . . . . . . . 9 77 4.2.2. EPP Command . . . . . . . . . . . . . . . . 11 78 4.2.3. EPP Command . . . . . . . . . . . . . . . . . 11 79 4.2.4. EPP Command . . . . . . . . . . . . . . . 11 80 4.2.5. EPP Command . . . . . . . . . . . . . . . . 12 81 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 82 5.1. Registry Lock Extension Schema . . . . . . . . . . . . . 15 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 84 6.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 17 85 6.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 17 86 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 89 10. Normative References . . . . . . . . . . . . . . . . . . . . 18 90 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 19 91 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 19 92 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 19 94 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 19 96 1. Introduction 98 This extensions defines an additional protective layer for changes to 99 domain [RFC5731], host [RFC5732] and contact [RFC5733] objects 100 managed through EPP. 102 EPP allows changes to objects only by the sponsoring client. EPP 103 objects are usually managed by the sponsoring client on behalf of the 104 sponsoring clients customers. All of these interactions are ususally 105 fully automated. 107 In case of a system breach, there is no protection in EPP to changes 108 to any object by the intruder. 110 This extension defines a protective layer that aims to break 111 automated changes and work flows by requiring manual intervention by 112 the sponsoring client or it's customers. 114 1.1. Conventions Used in This Document 116 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 117 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 118 document are to be interpreted as described in RFC 2119 [RFC2119]. 120 XML is case sensitive. Unless stated otherwise, XML specifications 121 and examples provided in this document MUST be interpreted in the 122 character case presented in order to develop a conforming 123 implementation. 125 In examples, "C:" represents lines sent by a protocol client and "S:" 126 represents lines returned by a protocol server. Indentation and 127 white space in examples are provided only to illustrate element 128 relationships and are not a REQUIRED feature of this protocol. 130 "regLock" is used as an abbreviation for 131 "urn:ietf:params:xml:ns:epp:registryLock-1.0". The XML namespace 132 prefix "reglock" is used, but implementations MUST NOT depend on it 133 and instead employ a proper namespace-aware XML parser and serializer 134 to interpret and output the XML documents. 136 2. Object Protection 138 This extension provides additional protection to objects managed by a 139 sponsoring client on behalf of a registrant. This is achieved by 140 requiring additional authorization for transform commands. 142 Solutions can be broadly categorized as in-band or out-of-band 143 authorizations. Where in-band authorizations would provide 144 authorization through EPP. Whereas out-of-band solutions provide 145 authorization by some other means. 147 either by temporarily unlocking the object for changes 148 or by authorizing pending changes after they have been submitted 149 to the server. 151 2.1. Password Authorization 153 In-band authorization uses the authorization possibilities provided 154 by EPP Standards [RFC5730], [RFC5731], [RFC5732] and [RFC5733]. 156 registryLock aims to break automatic changes to registry objects. A 157 registry implementing password authorization must make sure to secure 158 authorization in a way that breaks automation and requires human 159 interaction. One such scheme, although currently none is defined for 160 EPP, could be one time passwords. 162 With password authorization temporary unlock MUST not be implemented. 163 Every command could be authorized by including the 164 credentials in the command. 166 2.2. Out-of-band Authorization 168 Out-of-band Authorization is not covered in this document. By 169 definition out-of-band authorization will not use EPP and therefore 170 is not subject of consideration here. 172 Registries must provide means for the registrar or registrant to 173 temporarily unlock the domain, to remove registry lock or ro 174 authorize changes submitted to the server through some means than 175 EPP. 177 Any object that is locked with out-of-band authorization MUST reject 178 password authorization with EPP response code 2201 "Authorization 179 error" [RFC5730] section 3. 181 Any object that is locked with password authorization MUST reject 182 out-of-band authorization with EPP response code 2201 "Authorization 183 error" [RFC5730] section 3. 185 2.3. Command Execution Restrictions 187 Once an object has Registry Lock enabled all transform commands 188 except MUST only be executed if 189 proper authorization is provided or 190 the object is temporarily unlocked 192 Otherwise the command MUST be rejected with EPP result code 2201 193 "Authorization error" [RFC5730] section 3. 195 The following EPP flags [RFC5731], [RFC5732], [RFC5733] must be set. 197 serverDeleteProhibited 198 serverTransferProhibited 199 serverUpdateProhibited 201 If the object is unlocked the flags SHOULD be cleared and the server 202 should answer to an request with the according information. 203 However, if the object is only temporarily unlocked, only the 204 serverUpdateProhibited flag SHOULD be cleared, but in an 205 response the server should still indicate that the object is under 206 registry lock. 208 OPEN QUESTION: If a domain is under registry lock, can a subordinate 209 host be updated? 211 I got one "no" answer - hosts might not be owned by domain owner 212 In .se/.nu all subordinary hosts are automatically owned by the 213 domain owner and locked if the domain is locked. 215 We need more input! 217 3. Object Attributes 219 3.1. Locking Status 221 Locking Status information indicates if the additional protection of 222 Registry Lock is enabled for an object. 224 Boolean values MUST be represented in the XML Schema format described 225 in Part 2 of the W3C XML Schema recommendation [W3C.REC-xmlschema- 226 2-20010502]. 228 4. EPP Command Mapping 230 A detailed description of the EPP syntax and semantics can be found 231 in the EPP core protocol specification [RFC5730]. 233 4.1. EPP Query Commands 235 4.1.1. EPP Command 237 This extension does not add any elements to the EPP command 238 or response described in the EPP mappings [RFC5731], 239 [RFC5732] or [RFC5733]. 241 4.1.2. EPP Command 243 This extension does not add any elements to the EPP command 244 described in the EPP domain mapping [RFC5731], host mapping [RFC5732] 245 or contact mapping [RFC5733] However, additional elements are defined 246 for the response. 248 When an command has been processed successfully, the EPP 249 element MUST contain child elements as described in the EPP 250 object mappings. 252 In addition, the EPP element SHOULD contain a child 253 element that identifies the extension namespace the 254 epp client has indicated support for the extension in the 255 command. 257 The element contains the following child elements: 259 Exactly one element that indicates if Registry Lock is 260 enabled for the object. 261 An OPTIONAL element if the object currently can be 262 changed by the sponsoring client. The field indicates the time 263 stamp when the lock will become active again. 265 Example Response, domain not locked 267 S: 268 S: 270 S: 271 S: 272 S: Command completed successfully 273 S: 274 S: 275 S: 278 S: 279 S: 280 S: 281 S: 0 282 S: 283 S: 284 S: 285 S: ABC-12345 286 S: 54322-XYZ 287 S: 288 S: 289 S: 291 Example Response, domain locked 293 S: 294 S: 296 S: 297 S: 298 S: Command completed successfully 299 S: 300 S: 301 S: 304 S: 305 S: 306 S: 307 S: 1 308 S: 309 S: 310 S: 311 S: ABC-12345 312 S: 54322-XYZ 313 S: 314 S: 315 S: 317 Example Response, domain temporary unlocked 319 S: 320 S: 322 S: 323 S: 324 S: Command completed successfully 325 S: 326 S: 327 S: 330 S: 331 S: 332 S: 333 S: 1 334 S: 20000101T000000+0000 335 S: 336 S: 337 S: 338 S: ABC-12345 339 S: 54322-XYZ 340 S: 341 S: 342 S: 344 4.1.3. EPP Command 346 This extension does not add any elements to the EPP 347 command or response described in the EPP mapping 348 [RFC5731], [RFC5732] or [RFC5733]. 350 4.2. EPP Transform Commands 352 4.2.1. EPP Command 354 This extension is intended to be used within the scope of the object 355 creation. It does not define a command of its own. 357 This extension adds elements to both the EPP command and 358 response as described in the EPP [RFC5730]. 360 When submitting a command to the server, the client MAY 361 include in the element a element to 362 create the domain in a locked state. The extension includes the 363 following child element: 365 A element defining the mechanism of how the 366 domain can be unlocked. Valid values are "outofband" in order to 367 unlock the domain outside of EPP or "password" to unlock the 368 domain using a password. 369 An optional element that keeps the domain 370 temporarily unlocked, stating the time stamp when the lock should 371 become active. 373 When the command has been processed successfully, and the 374 client requested the creation of a locked domain, the server MUST 375 include in the section of the EPP response a 376 element that contains the following child element: 378 A element stating the locked state as being set. 379 An optional element if the domain has been 380 temporarily unlocked, stating the time stamp when the lock will 381 become active. 383 Example command 385 C: 386 C: 387 C: 388 C: 389 C: 391 C: ns1.example.com 392 C: 192.0.2.2 393 C: 192.0.2.29 394 C: 1080:0:0:0:8:800:200C:417A 395 C: 396 C: 397 C: 398 C: 399 C: outofband 400 C: 401 C: 402 C: ABC-12345 403 C: 404 C: 406 Example response 408 S: 409 S: 410 S: 411 S: 412 S: Command completed successfully 413 S: 414 S: 415 S: 416 S: 1 417 S: 418 S: 419 S: 420 S: ABC-12345 421 S: 54321-XYZ 422 S: 423 S: 424 S: 426 4.2.2. EPP Command 428 This extension does not add any elements to the EPP command 429 or response described in the EPP mappings [RFC5731], 430 [RFC5732] or [RFC5733]. 432 If the object is locked, the EPP command MUST be rejected 433 with EPP response code 2201 "Authorization error" [RFC5730] section 434 3. See Section 2.3 436 4.2.3. EPP Command 438 This extension does not add any elements to the EPP command 439 or response described in the EPP mappings [RFC5731], 440 [RFC5732] or [RFC5733]. 442 Execution of the EPP command is not restricted by this 443 extension. 445 4.2.4. EPP Command 447 This extension does not add any elements to the EPP 448 command or response described in the EPP mappings 449 [RFC5731], [RFC5732] or [RFC5733]. 451 If the object is locked, the EPP command MUST be rejected 452 with EPP response code 2201 "Authorization error" [RFC5730] section 453 3. See Section 2.3 455 4.2.5. EPP Command 457 This extension adds elements to both the EPP command and 458 response as described in [RFC5730]. 460 If the object is not locked, the command can be used to lock 461 the object, similarly to the command. 463 If the object is locked, the server MUST NOT except any command to 464 fully unlock the object. Only temporarily unlocking is acceptable. 466 If the object is locked the server can handle commands in 467 two ways 469 rejecting the command with EPP response code 1001 "Command 470 completed successfully; action pending" [RFC5730] section 3 471 answering with EPP response code 2201 "Authorization error" 472 [RFC5730] section 3 474 If the object is temporarily unlocked only commands are 475 allowed. and are explicitly not allowed. For 476 the time of the temporary unlock the serverUpdateProhibited status 477 should be cleared. 479 Registries can narrow down allowed changes when a domain is locked. 480 Registries could prohobit changes of registrant for doamins even if 481 the domain is temporatily unlocked or password authorization is 482 given. 484 When the > command has been processed successfully, and the 485 client included the regLock extension in the update request, the 486 server MUST include in the section of the EPP response a 487 element that contains the following child elements: 489 A element stating the locked state as being set. 490 An optional element if the domain has been 491 temporarily unlocked, stating the time stamp when the lock will 492 become active again. 494 Example command, locking domain 496 C: 497 C: 498 C: 499 C: 500 C: 502 C: example.com 503 C: 504 C: 505 C: 506 C: 507 C: outofband 508 C: 509 C: 510 C: ABC-12345 511 C: 512 C: 514 Example response 516 S: 517 S: 518 S: 519 S: 520 S: Command completed successfully 521 S: 522 S: 523 S: 524 S: 1 525 S: 526 S: 527 S: 528 S: ABC-12345 529 S: 54321-XYZ 530 S: 531 S: 532 S: 534 Example command, for temporary unlock of domain 536 C: 537 C: 538 C: 539 C: 540 C: 542 C: example.com 543 C: 544 C: 545 C: 546 C: 547 C: 20000101T000000+0000 548 C: 549 C: 550 C: ABC-12345 551 C: 552 C: 554 Example response, for temporary unlock of domain 556 S: 557 S: 558 S: 559 S: 560 S: Command completed successfully 561 S: 562 S: 563 S: 564 S: 1 565 S: 20000101T000000+0000 566 S: 567 S: 568 S: 569 S: ABC-12345 570 S: 54321-XYZ 571 S: 572 S: 573 S: 575 Example response, for failure of temporary unlock of 576 domain 578 S: 579 S: 580 S: 581 S: 582 S: Authorization error 583 S: 584 S: 585 S: 586 S: 1 587 S: 588 S: 589 S: 590 S: ABC-12345 591 S: 54321-XYZ 592 S: 593 S: 594 S: 596 5. Formal Syntax 598 One schema is presented here that is the EPP Registry Lock Extension 599 schema. 601 The formal syntax presented here is a complete schema representation 602 of the object mapping suitable for automated validation of EPP XML 603 instances. The BEGIN and END tags are not part of the schema; they 604 are used to note the beginning and ending of the schema for URI 605 registration purposes. 607 5.1. Registry Lock Extension Schema 609 BEGIN 610 611 616 617 618 Registry Lock Extension to the Extensible Provisioning Protocol v1.0 619 620 622 624 625 627 629 630 631 633 635 636 637 638 639 640 642 644 645 646 647 648 649 651 653 654 655 656 657 659 661 662 663 664 665 666 668 669 END 671 6. IANA Considerations 673 6.1. XML Namespace 675 This document uses URNs to describe XML namespaces and XML schemas 676 conforming to a registry mechanism described in [RFC3688]. The 677 following URI assignment is requested of IANA: 679 Registration request for the registryLock namespace: 681 URI: urn:ietf:params:xml:ns:epp:registryLock-1.0 682 Registrant Contact: IESG 683 XML: None. Namespace URIs do not represent an XML specification. 685 Registration request for the registryLock XML schema: 687 URI: urn:ietf:params:xml:schema:epp:registryLock-1.0 688 Registrant Contact: IESG 689 XML: See the "Formal Syntax" section of this document. 691 6.2. EPP Extension Registry 693 The EPP extension described in this document should be registered by 694 the IANA in the EPP Extension Registry described in [RFC7451]. The 695 details of the registration are as follows: 697 Name of Extension: "Registry Lock Extension for the Extensible 698 Provisioning Protocol (EPP)" 700 Document status: Standards Track 702 Reference: (insert reference to RFC version of this document) 704 Registrant Name and Email Address: IESG, 706 TLDs: Any 708 IPR Disclosure: None 710 Status: Active 712 Notes: None 714 7. Implementation Status 716 Note to RFC Editor: Please remove this section and the reference to 717 RFC 7942 [RFC7942] before publication. 719 Implemented by .SE since 2019. 721 8. Security Considerations 723 The security properties of EPP from [RFC5730] are preserved. 725 This extensions introduces an additional security layer for changes 726 of objects managed through EPP. The overall security of these 727 measures depends on policies and procedures not covered in this 728 document. 730 Registry should whenevr possible NOT implement password 731 authorization. Once the password is known to the EPP client and 732 number of changes could be authorized with it. Therefore a registry 733 implementing password authorization MUST take precautions so that 734 every update needs human interaction. 736 9. Acknowledgements 738 The authors wish to thank the following persons for their feedback 739 and suggestions: 741 10. Normative References 743 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 744 Requirement Levels", BCP 14, RFC 2119, 745 DOI 10.17487/RFC2119, March 1997, 746 . 748 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 749 DOI 10.17487/RFC3688, January 2004, 750 . 752 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 753 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 754 . 756 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 757 Domain Name Mapping", STD 69, RFC 5731, 758 DOI 10.17487/RFC5731, August 2009, 759 . 761 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 762 Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, 763 August 2009, . 765 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 766 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 767 August 2009, . 769 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 770 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 771 February 2015, . 773 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 774 Code: The Implementation Status Section", BCP 205, 775 RFC 7942, DOI 10.17487/RFC7942, July 2016, 776 . 778 [W3C.REC-xmlschema-2-20041028] 779 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 780 Second Edition", World Wide Web Consortium Recommendation 781 REC-xmlschema-2-20041028, October 2004, 782 . 784 Appendix A. Change History 786 A.1. Change from 00 to 01 788 1. Corrected information for the command. 789 2. Minor fixes in wording. 790 3. Introduces resData element. 792 A.2. Change from 01 to 02 794 1. Multiple spelling errors fixed. 795 2. Moved response from resData to extension part of the EPP 796 response. 797 3. Clarification of password and out-of-band usage. 798 4. Updated XML schema and examples 799 5. Changed security considerations for password authorization. 800 6. Added unlockUntil to create command 801 7. Forbid temporarily unlock for password authorization. 803 Author's Address 804 Ulrich Wisser 805 The Swedish Internet Infrastructure Foundation 806 Box 92073 807 Stockholm 12007 808 SE 810 Email: ulrich@wisser.se 811 URI: https://www.internetstiftelsen.se