idnits 2.17.1 draft-wisser-registrylock-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 14 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 23, 2019) is 1859 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 Network Working Group U. Wisser 3 Internet-Draft The Swedish Internet Infrastructure Foundation 4 Intended status: Standards Track March 23, 2019 5 Expires: September 24, 2019 7 Registry Lock Extension for the Extensible Provisioning Protocol (EPP) 8 draft-wisser-registrylock-00 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. There is no protection in EPP to 19 changes to an object by the sponsoring client that are not authorized 20 by the the customer. 22 This extension defines a protective layer that aims to break 23 automated changes and work flows by requiring manual intervention by 24 the sponsoring client or it's customers. 26 Status of This Memo 28 This Internet-Draft is submitted 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). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on September 24, 2019. 43 Copyright Notice 45 Copyright (c) 2019 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (https://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 62 2. Object Protection . . . . . . . . . . . . . . . . . . . . . . 3 63 2.1. In-band Authorization . . . . . . . . . . . . . . . . . . 4 64 2.2. Out-of-band Authorization . . . . . . . . . . . . . . . . 4 65 2.3. Command Execution Restrictions . . . . . . . . . . . . . 4 66 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Locking Status . . . . . . . . . . . . . . . . . . . . . 4 68 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5 69 4.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5 70 4.1.1. EPP Command . . . . . . . . . . . . . . . . . 5 71 4.1.2. EPP Command . . . . . . . . . . . . . . . . . 5 72 4.1.3. EPP Command . . . . . . . . . . . . . . . 8 73 4.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 8 74 4.2.1. EPP Command . . . . . . . . . . . . . . . . 8 75 4.2.2. EPP Command . . . . . . . . . . . . . . . . 10 76 4.2.3. EPP Command . . . . . . . . . . . . . . . . . 11 77 4.2.4. EPP Command . . . . . . . . . . . . . . . 11 78 4.2.5. EPP Command . . . . . . . . . . . . . . . . 11 79 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 13 80 5.1. Registry Lock Extension Schema . . . . . . . . . . . . . 13 81 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 82 6.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 14 83 6.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 15 84 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 15 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 87 10. Normative References . . . . . . . . . . . . . . . . . . . . 16 88 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 17 89 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 17 90 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 17 92 1. Introduction 94 This extensions defines an additional protective layer for changes to 95 domain [RFC5731], host [RFC5732] and contact [RFC5733] objects 96 managed through EPP. 98 EPP allows changes to objects only by the sponsoring client. EPP 99 objects are usually managed by the sponsoring client on behalf of the 100 sponsoring clients customers. There is no protection in EPP to 101 changes to an object by the sponsoring client that are not authorized 102 by the the customer. 104 This extension defines a protective layer that aims to break 105 automated changes and work flows by requiring manual intervention by 106 the sponsoring client or it's customers. 108 1.1. Conventions Used in This Document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 112 document are to be interpreted as described in RFC 2119 [RFC2119]. 114 XML is case sensitive. Unless stated otherwise, XML specifications 115 and examples provided in this document MUST be interpreted in the 116 character case presented in order to develop a conforming 117 implementation. 119 In examples, "C:" represents lines sent by a protocol client and "S:" 120 represents lines returned by a protocol server. Indentation and 121 white space in examples are provided only to illustrate element 122 relationships and are not a REQUIRED feature of this protocol. 124 "regLock" is used as an abbreviation for 125 "urn:ietf:params:xml:ns:epp:registryLock-1.0". The XML namespace 126 prefix "reglock" is used, but implementations MUST NOT depend on it 127 and instead employ a proper namespace-aware XML parser and serializer 128 to interpret and output the XML documents. 130 2. Object Protection 132 This extension provides additional protection to objects managed by a 133 sponsoring client on behalf of a registrant. This is achieved by 134 requiring additional authorization for transform commands. 136 Solutions can be broadly categorized as in-band or out-of-band 137 authorizations. Where in-band authorizations would provide 138 authorization through EPP. Whereas out-of-band solutions provide 139 authorization by some other means. 141 2.1. In-band Authorization 143 In-band authorization uses the authorization possibilities provided 144 by EPP Standards [RFC5730], [RFC5731], [RFC5732] and [RFC5733]. 146 2.2. Out-of-band Authorization 148 Out-of-band Authorization is not covered in this document. By 149 definition out of band authorization will not use EPP and therefor is 150 not subject of consideration here. 152 2.3. Command Execution Restrictions 154 Once an object has Registry Lock enabled all transform commands 155 except MUST only be executed if 157 proper authorization is provided 158 the object is unlocked out-of-band 160 Otherwise the command MUST be rejected with EPP result code 2201 161 "Authorization error" [RFC5730] section 3. 163 Additionally the following EPP flags [RFC5731], [RFC5731], [RFC5731] 164 must be set. 166 serverDeleteProhibited 167 serverTransferProhibited 168 serverUpdateProhibited 170 If the object is unlocked the flags SHOULD be cleared and the server 171 should answer to an request with the according information. 172 However, if the object is only temporarily unlocked, the flags SHOULD 173 be cleared, but in an response the server should still 174 indicate that the object is under registry lock. 176 OPEN QUESTION: If a domain is under registry lock, can a subordinate 177 host be update? 179 3. Object Attributes 181 3.1. Locking Status 183 Locking Status information indicates if the additional protection of 184 Registry Lock is enabled for an object. 186 Boolean values MUST be represented in the XML Schema format described 187 in Part 2 of the W3C XML Schema recommendation [W3C.REC-xmlschema- 188 2-20010502]. 190 4. EPP Command Mapping 192 A detailed description of the EPP syntax and semantics can be found 193 in the EPP core protocol specification [RFC5730]. 195 4.1. EPP Query Commands 197 4.1.1. EPP Command 199 This extension does not add any elements to the EPP command 200 or response described in the EPP mappings [RFC5731], 201 [RFC5732] or [RFC5733]. 203 4.1.2. EPP Command 205 This extension does not add any elements to the EPP command 206 described in the EPP domain mapping [RFC5731], host mapping [RFC5732] 207 or contact mapping [RFC5733] However, additional elements are defined 208 for the response. 210 When an command has been processed successfully, the EPP 211 element MUST contain child elements as described in the EPP 212 object mappings. 214 In addition, the EPP element SHOULD contain a child 215 element that identifies the extension namespace the 216 epp client has indicated support for the extension in the 217 command. 219 The element contains the following child elements: 221 Exactly one element that indicates if Registry Lock is 222 enabled for the object. 223 An OPTIONAL element if the object currently can be 224 changed by the sponsoring client. The field indicates the time 225 stamp when further changes will be impossible. 227 Example Response 229 S: 230 S: 232 S: 233 S: 234 S: Command completed successfully 235 S: 236 S: 237 S: 240 S: 241 S: 242 S: 243 S: 1 244 S: 20000101T000000+0000 245 S: 246 S: 247 S: 248 S: ABC-12345 249 S: 54322-XYZ 250 S: 251 S: 252 S: 254 Example Response 256 S: 257 S: 258 S: 259 S: 260 S: Command completed successfully 261 S: 262 S: 263 S: 265 ... 266 S: 267 S: 268 S: 269 S: 270 S: 1 271 S: 20000101T000000+0000 272 S: 273 S: 274 S: 275 S: ABC-12345 276 S: 54322-XYZ 277 S: 278 S: 279 S: 281 Example Response 283 S: 284 S: 285 S: 286 S: 287 S: Command completed successfully 288 S: 289 S: 290 S: 293 S: 294 S: 295 S: 296 S: 1 297 S: 20000101T000000+0000 298 S: 299 S: 300 S: 301 S: ABC-12345 302 S: 54322-XYZ 303 S: 304 S: 305 S: 307 4.1.3. EPP Command 309 This extension does not add any elements to the EPP 310 command or response described in the EPP domain mapping 311 [RFC5731], [RFC5732] or [RFC5733]. 313 4.2. EPP Transform Commands 315 4.2.1. EPP Command 317 This extension does not add any elements to the EPP response 318 described in the EPP mappings [RFC5731], [RFC5732] or [RFC5733]. 320 If the object is locked, the EPP command MUST be rejected 321 with EPP response code 2201 "Authorization error" [RFC5730] section 322 3. See Section 2.3 324 Example command 326 C: 327 C: 328 C: 329 C: 330 C: 332 C: example.com 333 C: 2 334 C: 335 C: ns1.example.net 336 C: ns2.example.net 337 C: 338 C: jd1234 339 C: sh8013 340 C: sh8013 341 C: 342 C: 2fooBAR 343 C: 344 C: 345 C: 346 C: 347 C: 348 C: outofband 349 C: 350 C: 351 C: ABC-12345 352 C: 353 C: 355 Example command 357 C: 358 C: 359 C: 360 C: 361 C: 363 C: ns1.example.com 364 C: 192.0.2.2 365 C: 192.0.2.29 366 C: 1080:0:0:0:8:800:200C:417A 367 C: 368 C: 369 C: 370 C: 371 C: outofband 372 C: 373 C: 374 C: ABC-12345 375 C: 376 C: 378 Example command 380 C: 381 C: 382 C: 383 C: 384 C: 386 ... 387 C: 388 C: 389 C: 390 C: 391 C: outofband 392 C: 393 C: 394 C: ABC-12345 395 C: 396 C: 398 4.2.2. EPP Command 400 This extension does not add any elements to the EPP command 401 or response described in the EPP mappings [RFC5731], 402 [RFC5732] or [RFC5733]. 404 The EPP command MUST be rejected with EPP response code 2201 405 "Authorization error" [RFC5730] section 3. See Section 2.3 407 4.2.3. EPP Command 409 This extension does not add any elements to the EPP command 410 or response described in the EPP mappings [RFC5731], 411 [RFC5732] or [RFC5733]. 413 Execution of the EPP command is not restricted by this 414 extension. 416 4.2.4. EPP Command 418 This extension does not add any elements to the EPP 419 command or response described in the EPP mappings 420 [RFC5731], [RFC5732] or [RFC5733]. 422 The EPP command MUST be rejected with EPP response code 423 2201 "Authorization error" [RFC5730] section 3. See Section 2.3 425 4.2.5. EPP Command 427 This extension does not add any elements to the EPP response 428 described in the EPP mappings [RFC5731], [RFC5732] or [RFC5733]. 430 If the object is locked, the EPP command MUST be rejected 431 with EPP response code 2201 "Authorization error" [RFC5730] section 432 3. See Section 2.3 434 Example Response 436 C: 437 C: 438 C: 439 C: 440 C: 442 C: example.com 443 C: 444 C: 445 C: 446 C: 447 C: outofband 448 C: 449 C: 450 C: ABC-12345 451 C: 452 C: 454 Example Response 456 C: 457 C: 458 C: 459 C: 460 C: 462 C: ns1.example.com 463 C: 464 C: 465 C: 466 C: 467 C: outofband 468 C: 469 C: 470 C: ABC-12345 471 C: 472 C: 474 Example Response 476 C: 477 C: 478 C: 479 C: 480 C: 482 C: sh8013 483 C: 484 C: 485 C: 486 C: 487 C: outofband 488 C: 489 C: 490 C: ABC-12345 491 C: 492 C: 494 5. Formal Syntax 496 One schema is presented here that is the EPP Registry Lock Extension 497 schema. 499 The formal syntax presented here is a complete schema representation 500 of the object mapping suitable for automated validation of EPP XML 501 instances. The BEGIN and END tags are not part of the schema; they 502 are used to note the beginning and ending of the schema for URI 503 registration purposes. 505 5.1. Registry Lock Extension Schema 506 BEGIN 507 508 513 514 515 Registry Lock Extension to the Extensible Provisioning Protocol v1.0 516 517 519 521 522 523 524 525 526 527 528 529 530 532 534 535 536 537 538 539 541 542 END 544 6. IANA Considerations 546 6.1. XML Namespace 548 This document uses URNs to describe XML namespaces and XML schemas 549 conforming to a registry mechanism described in [RFC3688]. The 550 following URI assignment is requested of IANA: 552 Registration request for the registryLock namespace: 554 URI: urn:ietf:params:xml:ns:epp:registryLock-1.0 555 Registrant Contact: IESG 556 XML: None. Namespace URIs do not represent an XML specification. 558 Registration request for the registryLock XML schema: 560 URI: urn:ietf:params:xml:schema:epp:registryLock-1.0 561 Registrant Contact: IESG 562 XML: See the "Formal Syntax" section of this document. 564 6.2. EPP Extension Registry 566 The EPP extension described in this document should be registered by 567 the IANA in the EPP Extension Registry described in [RFC7451]. The 568 details of the registration are as follows: 570 Name of Extension: "Registry Lock Extension for the Extensible 571 Provisioning Protocol (EPP)" 573 Document status: Standards Track 575 Reference: (insert reference to RFC version of this document) 577 Registrant Name and Email Address: IESG, 579 TLDs: Any 581 IPR Disclosure: None 583 Status: Active 585 Notes: None 587 7. Implementation Status 589 Note to RFC Editor: Please remove this section and the reference to 590 RFC 7942 [RFC7942] before publication. 592 TBD 594 8. Security Considerations 596 The security properties of EPP from [RFC5730] are preserved. 598 This extensions introduces an additional security layer for changes 599 of objects managed through EPP. The overall security of these 600 measures depends on policies and procedures not covered in this 601 document. 603 9. Acknowledgements 605 The authors wish to thank the following persons for their feedback 606 and suggestions: 608 10. Normative References 610 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 611 Requirement Levels", BCP 14, RFC 2119, 612 DOI 10.17487/RFC2119, March 1997, 613 . 615 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 616 DOI 10.17487/RFC3688, January 2004, 617 . 619 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 620 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 621 . 623 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 624 Domain Name Mapping", STD 69, RFC 5731, 625 DOI 10.17487/RFC5731, August 2009, 626 . 628 [RFC5732] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 629 Host Mapping", STD 69, RFC 5732, DOI 10.17487/RFC5732, 630 August 2009, . 632 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 633 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 634 August 2009, . 636 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 637 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 638 February 2015, . 640 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 641 Code: The Implementation Status Section", BCP 205, 642 RFC 7942, DOI 10.17487/RFC7942, July 2016, 643 . 645 [W3C.REC-xmlschema-2-20041028] 646 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 647 Second Edition", World Wide Web Consortium Recommendation 648 REC-xmlschema-2-20041028, October 2004, 649 . 651 Appendix A. Change History 653 A.1. Change from 00 to 01 655 1. None yet :-) 657 Author's Address 659 Ulrich Wisser 660 The Swedish Internet Infrastructure Foundation 661 Box 92073 662 Stockholm 12007 663 SE 665 Email: ulrich.wisser@internetstiftelsen.se 666 URI: https://www.internetstiftelsen.se