idnits 2.17.1 draft-wisser-registrylock-01.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 17 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 -- The document date (March 24, 2020) is 1493 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 (~~), 1 warning (==), 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 March 24, 2020 5 Expires: September 25, 2020 7 Registry Lock Extension for the Extensible Provisioning Protocol (EPP) 8 draft-wisser-registrylock-01 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 September 25, 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 . . . . . . . . . . . . . . . . . . . 5 72 4.1.1. EPP Command . . . . . . . . . . . . . . . . . 5 73 4.1.2. EPP Command . . . . . . . . . . . . . . . . . 5 74 4.1.3. EPP Command . . . . . . . . . . . . . . . 8 75 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 8 76 4.2.1. EPP Command . . . . . . . . . . . . . . . . 8 77 4.2.2. EPP Command . . . . . . . . . . . . . . . . 9 78 4.2.3. EPP Command . . . . . . . . . . . . . . . . . 10 79 4.2.4. EPP Command . . . . . . . . . . . . . . . 10 80 4.2.5. EPP Command . . . . . . . . . . . . . . . . 10 81 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 82 5.1. Registry Lock Extension Schema . . . . . . . . . . . . . 13 83 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 84 6.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 14 85 6.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 15 86 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 87 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 88 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 89 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 90 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 17 91 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 17 92 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 94 1. Introduction 96 This extensions defines an additional protective layer for changes to 97 domain [RFC5731], host [RFC5732] and contact [RFC5733] objects 98 managed through EPP. 100 EPP allows changes to objects only by the sponsoring client. EPP 101 objects are usually managed by the sponsoring client on behalf of the 102 sponsoring clients customers. All of these interactions are ususally 103 fully automated. 105 In case of a system breach, there is no protection in EPP to changes 106 to any object by the intruder. 108 This extension defines a protective layer that aims to break 109 automated changes and work flows by requiring manual intervention by 110 the sponsoring client or it's customers. 112 1.1. Conventions Used in This Document 114 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 115 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 116 document are to be interpreted as described in RFC 2119 [RFC2119]. 118 XML is case sensitive. Unless stated otherwise, XML specifications 119 and examples provided in this document MUST be interpreted in the 120 character case presented in order to develop a conforming 121 implementation. 123 In examples, "C:" represents lines sent by a protocol client and "S:" 124 represents lines returned by a protocol server. Indentation and 125 white space in examples are provided only to illustrate element 126 relationships and are not a REQUIRED feature of this protocol. 128 "regLock" is used as an abbreviation for 129 "urn:ietf:params:xml:ns:epp:registryLock-1.0". The XML namespace 130 prefix "reglock" is used, but implementations MUST NOT depend on it 131 and instead employ a proper namespace-aware XML parser and serializer 132 to interpret and output the XML documents. 134 2. Object Protection 136 This extension provides additional protection to objects managed by a 137 sponsoring client on behalf of a registrant. This is achieved by 138 requiring additional authorization for transform commands. 140 Solutions can be broadly categorized as in-band or out-of-band 141 authorizations. Where in-band authorizations would provide 142 authorization through EPP. Whereas out-of-band solutions provide 143 authorization by some other means. 145 2.1. Password Authorization 147 In-band authorization uses the authorization possibilities provided 148 by EPP Standards [RFC5730], [RFC5731], [RFC5732] and [RFC5733]. 150 Registries implementing in-band authorization should consider to 151 require more secure passwords as specified in draft-ietf-regext- 152 login-security. 154 2.2. Out-of-band Authorization 156 Out-of-band Authorization is not covered in this document. By 157 definition out of band authorization will not use EPP and therefor is 158 not subject of consideration here. 160 2.3. Command Execution Restrictions 162 Once an object has Registry Lock enabled all transform commands 163 except MUST only be executed if 165 proper authorization is provided 166 the object is unlocked 168 Otherwise the command MUST be rejected with EPP result code 2201 169 "Authorization error" [RFC5730] section 3. 171 The following EPP flags [RFC5731], [RFC5732], [RFC5733] must be set. 173 serverDeleteProhibited 174 serverTransferProhibited 175 serverUpdateProhibited 177 If the object is unlocked the flags SHOULD be cleared and the server 178 should answer to an request with the according information. 179 However, if the object is only temporarily unlocked, the flags SHOULD 180 be cleared, but in an response the server should still 181 indicate that the object is under registry lock. 183 OPEN QUESTION: If a domain is under registry lock, can a subordinate 184 host be updated? 186 3. Object Attributes 188 3.1. Locking Status 190 Locking Status information indicates if the additional protection of 191 Registry Lock is enabled for an object. 193 Boolean values MUST be represented in the XML Schema format described 194 in Part 2 of the W3C XML Schema recommendation [W3C.REC-xmlschema- 195 2-20010502]. 197 4. EPP Command Mapping 199 A detailed description of the EPP syntax and semantics can be found 200 in the EPP core protocol specification [RFC5730]. 202 4.1. EPP Query Commands 204 4.1.1. EPP Command 206 This extension does not add any elements to the EPP command 207 or response described in the EPP mappings [RFC5731], 208 [RFC5732] or [RFC5733]. 210 4.1.2. EPP Command 212 This extension does not add any elements to the EPP command 213 described in the EPP domain mapping [RFC5731], host mapping [RFC5732] 214 or contact mapping [RFC5733] However, additional elements are defined 215 for the response. 217 When an command has been processed successfully, the EPP 218 element MUST contain child elements as described in the EPP 219 object mappings. 221 In addition, the EPP element SHOULD contain a child 222 element that identifies the extension namespace the 223 epp client has indicated support for the extension in the 224 command. 226 The element contains the following child elements: 228 Exactly one element that indicates if Registry Lock is 229 enabled for the object. 230 An OPTIONAL element if the object currently can be 231 changed by the sponsoring client. The field indicates the time 232 stamp when further changes will be impossible. 234 Example Response, domain not locked 236 S: 237 S: 239 S: 240 S: 241 S: Command completed successfully 242 S: 243 S: 244 S: 247 S: 248 S: 249 S: 250 S: 0 251 S: 252 S: 253 S: 254 S: ABC-12345 255 S: 54322-XYZ 256 S: 257 S: 258 S: 260 Example Response, domain locked 262 S: 263 S: 265 S: 266 S: 267 S: Command completed successfully 268 S: 269 S: 270 S: 273 S: 274 S: 275 S: 276 S: 1 277 S: 20000101T000000+0000 278 S: 279 S: 280 S: 281 S: ABC-12345 282 S: 54322-XYZ 283 S: 284 S: 285 S: 287 Example Response, domain temporary unlocked 289 S: 290 S: 292 S: 293 S: 294 S: Command completed successfully 295 S: 296 S: 297 S: 300 S: 301 S: 302 S: 303 S: 1 304 S: 20000101T000000+0000 305 S: 306 S: 307 S: 308 S: ABC-12345 309 S: 54322-XYZ 310 S: 311 S: 312 S: 314 4.1.3. EPP Command 316 This extension does not add any elements to the EPP 317 command or response described in the EPP domain mapping 318 [RFC5731], [RFC5732] or [RFC5733]. 320 4.2. EPP Transform Commands 322 4.2.1. EPP Command 324 This extension does add an element to the EPP 325 response as described in the EPP [RFC5730]. 327 This extension is inteded to be used within the scope of the object 328 creation. It does not define a command of it's own. 330 Example command 332 C: 333 C: 334 C: 335 C: 336 C: 338 C: ns1.example.com 339 C: 192.0.2.2 340 C: 192.0.2.29 341 C: 1080:0:0:0:8:800:200C:417A 342 C: 343 C: 344 C: 345 C: 346 C: outofband 347 C: 348 C: 349 C: ABC-12345 350 C: 351 C: 353 Example response 355 S: 356 S: 357 S: 358 S: 359 S: Command completed successfully 360 S: 361 S: 362 S: 363 S: 1 364 S: 365 S: 366 S: 367 S: ABC-12345 368 S: 54321-XYZ 369 S: 370 S: 371 S: 373 4.2.2. EPP Command 375 This extension does not add any elements to the EPP command 376 or response described in the EPP mappings [RFC5731], 377 [RFC5732] or [RFC5733]. 379 If the object is locked, the EPP command MUST be rejected 380 with EPP response code 2201 "Authorization error" [RFC5730] section 381 3. See Section 2.3 383 4.2.3. EPP Command 385 This extension does not add any elements to the EPP command 386 or response described in the EPP mappings [RFC5731], 387 [RFC5732] or [RFC5733]. 389 Execution of the EPP command is not restricted by this 390 extension. 392 4.2.4. EPP Command 394 This extension does not add any elements to the EPP 395 command or response described in the EPP mappings 396 [RFC5731], [RFC5732] or [RFC5733]. 398 If the object is locked, the EPP command MUST be rejected 399 with EPP response code 2201 "Authorization error" [RFC5730] section 400 3. See Section 2.3 402 4.2.5. EPP Command 404 This extension does add an elements to the EPP 405 section of the response as described in [RFC5730]. 407 If the object is locked, the EPP the only allowed 408 command is a temporary unlock. All other commands MUST be 409 rejected with EPP response code 2201 "Authorization error" [RFC5730] 410 section 3. See Section 2.3 412 If the object is temporarily unlocked only commands are 413 allowed. and are explicitly not allowed. 414 Registries can further narrow down allowed changes, e.g. registries 415 could prohobit changes of registrant for doamins even under temporary 416 unlock. 418 IF the object is temporarily unlocked, the SEVER_UPDATE_PROHIBITED 419 status should be cleared for the time of the temporary unock. 421 Example command, locking domain 423 C: 424 C: 425 C: 426 C: 427 C: 429 C: example.com 430 C: 431 C: 432 C: 433 C: 434 C: outofband 435 C: 436 C: 437 C: ABC-12345 438 C: 439 C: 441 Example response 443 S: 444 S: 445 S: 446 S: 447 S: Command completed successfully 448 S: 449 S: 450 S: 451 S: 1 452 S: 453 S: 454 S: 455 S: ABC-12345 456 S: 54321-XYZ 457 S: 458 S: 459 S: 461 Example command, for temporary unlock of domain 463 C: 464 C: 465 C: 466 C: 467 C: 469 C: example.com 470 C: 471 C: ****** 472 C: 473 C: 474 C: 475 C: 476 C: 477 C: 20000101T000000+0000 478 C: 479 C: 480 C: ABC-12345 481 C: 482 C: 484 Example response, for temporary unlock of domain 486 S: 487 S: 488 S: 489 S: 490 S: Command completed successfully 491 S: 492 S: 493 S: 494 S: 1 495 S: 20000101T000000+0000 496 S: 497 S: 498 S: 499 S: ABC-12345 500 S: 54321-XYZ 501 S: 502 S: 503 S: 505 Example response, for failure of temporary unlock of 506 domain 508 S: 509 S: 510 S: 511 S: 512 S: Authorization error 513 S: 514 S: 515 S: 516 S: 1 517 S: 518 S: 519 S: 520 S: ABC-12345 521 S: 54321-XYZ 522 S: 523 S: 524 S: 526 5. Formal Syntax 528 One schema is presented here that is the EPP Registry Lock Extension 529 schema. 531 The formal syntax presented here is a complete schema representation 532 of the object mapping suitable for automated validation of EPP XML 533 instances. The BEGIN and END tags are not part of the schema; they 534 are used to note the beginning and ending of the schema for URI 535 registration purposes. 537 5.1. Registry Lock Extension Schema 538 BEGIN 539 540 545 546 547 Registry Lock Extension to the Extensible Provisioning Protocol v1.0 548 549 551 553 554 555 556 557 558 559 560 561 562 563 565 567 568 569 570 571 572 574 575 END 577 6. IANA Considerations 579 6.1. XML Namespace 581 This document uses URNs to describe XML namespaces and XML schemas 582 conforming to a registry mechanism described in [RFC3688]. The 583 following URI assignment is requested of IANA: 585 Registration request for the registryLock namespace: 587 URI: urn:ietf:params:xml:ns:epp:registryLock-1.0 588 Registrant Contact: IESG 589 XML: None. Namespace URIs do not represent an XML specification. 591 Registration request for the registryLock XML schema: 593 URI: urn:ietf:params:xml:schema:epp:registryLock-1.0 594 Registrant Contact: IESG 595 XML: See the "Formal Syntax" section of this document. 597 6.2. EPP Extension Registry 599 The EPP extension described in this document should be registered by 600 the IANA in the EPP Extension Registry described in [RFC7451]. The 601 details of the registration are as follows: 603 Name of Extension: "Registry Lock Extension for the Extensible 604 Provisioning Protocol (EPP)" 606 Document status: Standards Track 608 Reference: (insert reference to RFC version of this document) 610 Registrant Name and Email Address: IESG, 612 TLDs: Any 614 IPR Disclosure: None 616 Status: Active 618 Notes: None 620 7. Implementation Status 622 Note to RFC Editor: Please remove this section and the reference to 623 RFC 7942 [RFC7942] before publication. 625 Implemented by .SE since 2019. 627 8. Security Considerations 629 The security properties of EPP from [RFC5730] are preserved. 631 This extensions introduces an additional security layer for changes 632 of objects managed through EPP. The overall security of these 633 measures depends on policies and procedures not covered in this 634 document. 636 9. Acknowledgements 638 The authors wish to thank the following persons for their feedback 639 and suggestions: 641 10. Normative References 643 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 644 Requirement Levels", BCP 14, RFC 2119, 645 DOI 10.17487/RFC2119, March 1997, 646 . 648 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 649 DOI 10.17487/RFC3688, January 2004, 650 . 652 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 653 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 654 . 656 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 657 Domain Name Mapping", STD 69, RFC 5731, 658 DOI 10.17487/RFC5731, August 2009, 659 . 661 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 662 Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, 663 August 2009, . 665 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 666 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 667 August 2009, . 669 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 670 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 671 February 2015, . 673 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 674 Code: The Implementation Status Section", BCP 205, 675 RFC 7942, DOI 10.17487/RFC7942, July 2016, 676 . 678 [W3C.REC-xmlschema-2-20041028] 679 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 680 Second Edition", World Wide Web Consortium Recommendation 681 REC-xmlschema-2-20041028, October 2004, 682 . 684 Appendix A. Change History 686 A.1. Change from 00 to 01 688 1. Corrected information for the command. 689 2. Minor fixes in wording. 690 3. Introduces resData element. 692 Author's Address 694 Ulrich Wisser 695 The Swedish Internet Infrastructure Foundation 696 Box 92073 697 Stockholm 12007 698 SE 700 Email: ulrich@wisser.se 701 URI: https://www.internetstiftelsen.se