idnits 2.17.1 draft-ietf-regext-allocation-token-05.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 2, 2018) is 2305 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 6982 (Obsoleted by RFC 7942) ** Downref: Normative reference to an Informational RFC: RFC 7451 Summary: 2 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 J. Gould 3 Internet-Draft VeriSign, Inc. 4 Intended status: Standards Track K. Feher 5 Expires: July 6, 2018 Neustar 6 January 2, 2018 8 Allocation Token Extension for the Extensible Provisioning Protocol 9 (EPP) 10 draft-ietf-regext-allocation-token-05 12 Abstract 14 This document describes an Extensible Provisioning Protocol (EPP) 15 extension for including an allocation token or for allocating an 16 object like a domain name to the client. The allocation token MAY be 17 transferred out-of-band to a client to give them authorization to 18 allocate an object using one of the EPP transform commands including 19 create, update, and transfer. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on July 6, 2018. 38 Copyright Notice 40 Copyright (c) 2018 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 57 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 58 2.1. Allocation Token . . . . . . . . . . . . . . . . . . . . 3 59 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4 60 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 4 61 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 4 62 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 63 3.1.3. EPP Command . . . . . . . . . . . . . . . 10 64 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 11 65 3.2.1. EPP Command . . . . . . . . . . . . . . . . 11 66 3.2.2. EPP Command . . . . . . . . . . . . . . . . 12 67 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 12 68 3.2.4. EPP Command . . . . . . . . . . . . . . . 12 69 3.2.5. EPP Command . . . . . . . . . . . . . . . . 13 70 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 71 4.1. Allocation Token Extension Schema . . . . . . . . . . . . 15 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 73 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 15 74 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 16 75 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 76 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 17 77 6.2. Neustar EPP SDK . . . . . . . . . . . . . . . . . . . . . 17 78 6.3. Neustar gTLD SRS . . . . . . . . . . . . . . . . . . . . 17 79 7. Security Considerations . . . . . . . . . . . . . . . . . . . 18 80 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 81 9. Normative References . . . . . . . . . . . . . . . . . . . . 18 82 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 19 83 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 19 84 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 19 85 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 19 86 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 19 87 A.5. Change from 04 to REGEXT 00 . . . . . . . . . . . . . . . 19 88 A.6. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 19 89 A.7. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 20 90 A.8. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 20 91 A.9. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 20 92 A.10. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 20 93 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 95 1. Introduction 97 This document describes an extension mapping for version 1.0 of the 98 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 99 extension to EPP object mappings like the EPP domain name mapping 100 [RFC5731], for passing an allocation token to one of the EPP 101 transform commands including create, update, and transfer. A client 102 MUST pass an allocation token known to the server to be authorized to 103 use one of the supported EPP transform commands. It is up to server 104 policy which EPP transform commands and which objects support the 105 allocation token. The allocation token MAY be returned to an 106 authorized client for passing out-of-band to a client that uses it 107 with an EPP transform command. 109 1.1. Conventions Used in This Document 111 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 112 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 113 document are to be interpreted as described in RFC 2119 [RFC2119]. 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 in order to develop a conforming 118 implementation. 120 In examples, "C:" represents lines sent by a protocol client and "S:" 121 represents lines returned by a protocol server. Indentation and 122 white space in examples are provided only to illustrate element 123 relationships and are not a REQUIRED feature of this protocol. 125 "allocationToken-1.0" is used as an abbreviation for 126 "urn:ietf:params:xml:ns:allocationToken-1.0". The XML namespace 127 prefix "allocationToken" is used, but implementations MUST NOT depend 128 on it and instead employ a proper namespace-aware XML parser and 129 serializer to interpret and output the XML documents. 131 2. Object Attributes 133 This extension adds additional elements to EPP object mappings like 134 the EPP domain name mapping [RFC5731]. Only those new elements are 135 described here. 137 2.1. Allocation Token 139 The Allocation Token is a simple XML "token" type. The exact format 140 of the Allocation Token is up to server policy. The server MUST have 141 the allocation token for each object to match against the allocation 142 token passed by the client to authorize the allocation of the object. 144 The same element is used for all of 145 the supported EPP transform commands as well as the info response. 146 If an invalid allocation token is passed the server MUST return an 147 EPP error result code of 2201. 149 An example element with value of 150 "abc123": 152 154 abc123 155 157 3. EPP Command Mapping 159 A detailed description of the EPP syntax and semantics can be found 160 in the EPP core protocol specification [RFC5730]. 162 3.1. EPP Query Commands 164 EPP provides three commands to retrieve object information: 165 to determine if an object is known to the server, to retrieve 166 detailed information associated with an object, and to 167 retrieve object transfer status information. 169 3.1.1. EPP Command 171 This extension defines additional elements to extend the EPP 172 command of an object mapping like [RFC5731]. 174 This extension allow clients to check the availability of an object 175 with an allocation token, as described in Section 2.1. Clients can 176 check if an object can be created using the allocation token. The 177 allocation token is applied to all object names included in the EPP 178 command. 180 Example command for the example.tld domain name using the 181 extension with the allocation token 182 of 'abc123': 184 C: 185 C: 186 C: 187 C: 188 C: 190 C: example.tld 191 C: 192 C: 193 C: 194 C: 197 C: abc123 198 C: 199 C: 200 C: ABC-12345 201 C: 202 C: 204 If the query was successful, the server replies with an 205 response providing availability status of queried object. 207 Example domain response for a command using the 208 extension: 210 S: 211 S: 212 S: 213 S: 214 S: Command completed successfully 215 S: 216 S: 217 S: 219 S: 220 S: example.tld 221 S: Invalid domain-token pair 222 S: 223 S: 224 S: 225 S: 226 S: ABC-DEF-12345 227 S: 54321-XYZ 228 S: 229 S: 230 S: 231 Example command with the 232 extension for the example.tld and example2.tld domain names. 233 Availability of example.tld and example2.tld domain names are based 234 on the allocation token 'abc123': 236 C: 237 C: 238 C: 239 C: 240 C: 242 C: example.tld 243 C: example2.tld 244 C: 245 C: 246 C: 247 C: 250 C: abc123 251 C: 252 C: 253 C: ABC-DEF-12345 254 C: 255 C: 256 Example domain response for multiple domain names in the 257 command using the 258 extension: 260 S: 261 S: 262 S: 263 S: 264 S: Command completed successfully 265 S: 266 S: 267 S: 269 S: 270 S: example.tld 271 S: Invalid domain-token pair 272 S: 273 S: 274 S: example2.tld 275 S: 276 S: 277 S: 278 S: 279 S: ABC-DEF-12345 280 S: 54321-XYZ 281 S: 282 S: 283 S: 285 This extension does not add any elements to the EPP response 286 described in the [RFC5730]. 288 3.1.2. EPP Command 290 This extension defines additional elements to extend the EPP 291 command of an object mapping like [RFC5731]. 293 The EPP command allows a client to request information on an 294 existing object. Authorized clients MAY retrieve the allocation 295 token (Section 2.1) along with the other object information using the 296 element that identifies the extension 297 namespace. The element is an empty element 298 that serves as a marker to the server to return the 299 element, defined in Section 2.1, in 300 the info response. If the client is not authorized to receive the 301 allocation token (Section 2.1), the server MUST return an EPP error 302 result code of 2201. If the client is authorized to receive the 303 allocation token (Section 2.1), but there is no allocation token 304 (Section 2.1) associated with the object, the server MUST return an 305 EPP error result code of 2303 object referencing the 306 element. 308 Example command with the allocationToken:info extension for 309 the example.tld domain name: 311 C: 312 C: 313 C: 314 C: 315 C: 319 C: example.tld 320 C: 321 C: 322 C: 323 C: 326 C: 327 C: ABC-12345 328 C: 329 C: 331 If the query was successful, the server replies with an 332 element, as described in 333 Section 2.1. 335 Example domain response using the 336 extension: 338 S: 339 S: 340 S: 341 S: 342 S: Command completed successfully 343 S: 344 S: 345 S: 347 S: example.tld 348 S: EXAMPLE1-REP 349 S: 350 S: jd1234 351 S: sh8013 352 S: sh8013 353 S: ClientX 354 S: ClientY 355 S: 2012-04-03T22:00:00.0Z 356 S: 357 S: 2fooBAR 358 S: 359 S: 360 S: 361 S: 362 S: 365 S: abc123 366 S: 367 S: 368 S: 369 S: ABC-12345 370 S: 54321-XYZ 371 S: 372 S: 373 S: 375 3.1.3. EPP Command 377 This extension does not add any elements to the EPP query 378 command or response described in the [RFC5730]. 380 3.2. EPP Transform Commands 382 EPP provides five commands to transform objects: to create 383 an instance of an object, to delete an instance of an 384 object, to extend the validity period of an object, 385 to manage object sponsorship changes, and to 386 change information associated with an object. 388 3.2.1. EPP Command 390 This extension defines additional elements to extend the EPP 391 command of an object mapping like [RFC5731]. 393 The EPP command provides a transform operation that allows a 394 client to create an object. In addition to the EPP command elements 395 described in an object mapping like [RFC5731], the command MUST 396 contain a child element, as defined 397 in Section 2.1, that identifies the extension namespace for the 398 client to be authorized to create and allocate the object. If the 399 allocation token (Section 2.1) does not match the object's allocation 400 token (Section 2.1), the server MUST return an EPP error result code 401 of 2201.: 403 Example command to create a domain object with an allocation 404 token: 406 C: 407 C: 408 C: 409 C: 410 C: 412 C: example.tld 413 C: jd1234 414 C: sh8013 415 C: sh8013 416 C: 417 C: 2fooBAR 418 C: 419 C: 420 C: 421 C: 422 C: 425 C: abc123 426 C: 427 C: 428 C: ABC-12345 429 C: 430 C: 432 This extension does not add any elements to the EPP response 433 described in the [RFC5730]. 435 3.2.2. EPP Command 437 This extension does not add any elements to the EPP command 438 or response described in the [RFC5730]. 440 3.2.3. EPP Command 442 This extension does not add any elements to the EPP command 443 or response described in the [RFC5730]. 445 3.2.4. EPP Command 447 This extension defines additional elements to extend the EPP 448 request command of an object mapping like [RFC5731]. 450 The EPP request command provides a transform operation 451 that allows a client to request the transfer of an object. In 452 addition to the EPP command elements described in an object mapping 453 like [RFC5731], the command MUST contain a child 454 element, as defined in Section 2.1, 455 that identifies the extension namespace for the client to be 456 authorized to transfer and allocate the object. If the allocation 457 token (Section 2.1) does not match the object's allocation token 458 (Section 2.1), the server MUST return an EPP error result code of 459 2201. 461 Example request command to allocate the domain object with 462 the allocation token: 464 C: 465 C: 466 C: 467 C: 468 C: 470 C: example1.tld 471 C: 1 472 C: 473 C: 2fooBAR 474 C: 475 C: 476 C: 477 C: 478 C: 481 C: abc123 482 C: 483 C: 484 C: ABC-12345 485 C: 486 C: 488 This extension does not add any elements to the EPP 489 response described in the [RFC5730]. 491 3.2.5. EPP Command 493 This extension defines additional elements to extend an extension of 494 an empty EPP command of an object mapping like [RFC5731]. 495 An example of an extension of an empty EPP command is the 496 definition of the restore command within [RFC3915]. 498 An extension of an empty EPP command defines a new verb that 499 transforms an object. In addition to the EPP command elements 500 described in an object mapping like [RFC5731], the command MUST 501 contain a child element, as defined 502 in Section 2.1, that identifies the extension namespace for the 503 client to be authorized to allocate the object. If the allocation 504 token (Section 2.1) does not match the object's allocation token 505 (Section 2.1), the server MUST return an EPP error result code of 506 2201. 508 Example use an extension of an empty command to release a 509 domain object with an allocation token: 511 C: 512 C: 513 C: 514 C: 515 C: 517 C: example1.tld 518 C: 519 C: 520 C: 521 C: 523 C: 526 C: abc123 527 C: 528 C: 529 C: ABC-12345-XYZ 530 C: 531 C: 533 This extension does not add any elements to the EPP response 534 described in the [RFC5730]. 536 4. Formal Syntax 538 One schema is presented here that is the EPP Allocation Token 539 Extension schema. 541 The formal syntax presented here is a complete schema representation 542 of the object mapping suitable for automated validation of EPP XML 543 instances. The BEGIN and END tags are not part of the schema; they 544 are used to note the beginning and ending of the schema for URI 545 registration purposes. 547 4.1. Allocation Token Extension Schema 549 BEGIN 550 552 557 558 559 Extensible Provisioning Protocol v1.0 560 Allocation Token Extension. 561 562 564 565 567 569 572 573 574 575 576 578 579 580 END 582 5. IANA Considerations 584 5.1. XML Namespace 586 This document uses URNs to describe XML namespaces and XML schemas 587 conforming to a registry mechanism described in [RFC3688]. The 588 following URI assignment is requested of IANA: 590 URI: ietf:params:xml:ns:allocationToken-1.0 592 Registrant Contact: See the "Author's Address" section of this 593 document. 595 XML: See the "Formal Syntax" section of this document. 597 5.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: "Allocation Token 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 6. Implementation Status 622 Note to RFC Editor: Please remove this section and the reference to 623 RFC 6982 [RFC6982] before publication. 625 This section records the status of known implementations of the 626 protocol defined by this specification at the time of posting of this 627 Internet-Draft, and is based on a proposal described in RFC 6982 628 [RFC6982]. The description of implementations in this section is 629 intended to assist the IETF in its decision processes in progressing 630 drafts to RFCs. Please note that the listing of any individual 631 implementation here does not imply endorsement by the IETF. 632 Furthermore, no effort has been spent to verify the information 633 presented here that was supplied by IETF contributors. This is not 634 intended as, and must not be construed to be, a catalog of available 635 implementations or their features. Readers are advised to note that 636 other implementations may exist. 638 According to RFC 6982 [RFC6982], "this will allow reviewers and 639 working groups to assign due consideration to documents that have the 640 benefit of running code, which may serve as evidence of valuable 641 experimentation and feedback that have made the implemented protocols 642 more mature. It is up to the individual working groups to use this 643 information as they see fit". 645 6.1. Verisign EPP SDK 647 Organization: Verisign Inc. 649 Name: Verisign EPP SDK 651 Description: The Verisign EPP SDK includes both a full client 652 implementation and a full server stub implementation of draft-ietf- 653 regext-allocation-token. 655 Level of maturity: Production 657 Coverage: All aspects of the protocol are implemented. 659 Licensing: GNU Lesser General Public License 661 Contact: jgould@verisign.com 663 URL: https://www.verisign.com/en_US/channel-resources/domain- 664 registry-products/epp-sdks 666 6.2. Neustar EPP SDK 668 Organisation: Neustar Inc. 670 Name: Neustar EPP SDK 672 Description: The Neustar EPP SDK includes a full client 673 implementation of draft-ietf-regext-allocation-token. 675 Level of maturity: Production 677 Coverage: All aspects of the protocol are implemented. 679 Licensing: GNU Lesser General Public License 681 Contact: kal.feher@team.neustar 683 URL: http://registrytoolkit.neustar 685 6.3. Neustar gTLD SRS 687 Organisation: Neustar Inc. 689 Name: Neustar generic Top Level Domain (gTLD) Shared Registry System 690 (SRS). 692 Description: The Neustar gTLD SRS implements the server side of 693 draft-ietf-regext-allocation-token. For several Top Level Domains 695 Level of maturity: Production 697 Coverage: All server side aspects of the protocol are implemented. 699 Licensing: Proprietary 701 Contact: kal.feher@team.neustar 703 7. Security Considerations 705 The mapping extensions described in this document do not provide any 706 security services beyond those described by EPP [RFC5730] and 707 protocol layers used by EPP. The security considerations described 708 in these other specifications apply to this specification as well. 710 8. Acknowledgements 712 The authors wish to acknowledge the original concept for this draft 713 and the efforts in the initial versions of this draft by Trung Tran 714 and Sharon Wodjenski. 716 Special suggestions that have been incorporated into this document 717 were provided by Patrick Mevzek. 719 9. Normative References 721 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 722 Requirement Levels", BCP 14, RFC 2119, 723 DOI 10.17487/RFC2119, March 1997, . 726 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 727 DOI 10.17487/RFC3688, January 2004, . 730 [RFC3915] Hollenbeck, S., "Domain Registry Grace Period Mapping for 731 the Extensible Provisioning Protocol (EPP)", RFC 3915, 732 DOI 10.17487/RFC3915, September 2004, . 735 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 736 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 737 . 739 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 740 Domain Name Mapping", STD 69, RFC 5731, 741 DOI 10.17487/RFC5731, August 2009, . 744 [RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 745 Code: The Implementation Status Section", RFC 6982, 746 DOI 10.17487/RFC6982, July 2013, . 749 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 750 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 751 February 2015, . 753 Appendix A. Change History 755 A.1. Change from 00 to 01 757 1. Amended XML Namespace section of IANA Considerations, added EPP 758 Extension Registry section. 759 2. Moved Change History to the back section as an Appendix. 761 A.2. Change from 01 to 02 763 1. Ping update. 765 A.3. Change from 02 to 03 767 1. Ping update. 769 A.4. Change from 03 to 04 771 1. Updated the authors for the draft. 773 A.5. Change from 04 to REGEXT 00 775 1. Changed to regext working group draft by changing draft-gould- 776 allocation-token to draft-ietf-regext-allocation-token. 778 A.6. Change from REGEXT 00 to REGEXT 01 780 1. Ping update. 782 A.7. Change from REGEXT 01 to REGEXT 02 784 1. Added the Implementation Status section. 786 A.8. Change from REGEXT 02 to REGEXT 03 788 1. Changed Neustar author to Kal Feher. 790 A.9. Change from REGEXT 03 to REGEXT 04 792 1. Added Neustar implementation to the Implementation Status 793 section. 795 A.10. Change from REGEXT 04 to REGEXT 05 797 1. Updates based on feedback from Patrick Mevzek, that include: 799 1. Remove "or code" from the Abstract section. 800 2. Add a missing "to" in "an allocation token TO one of the 801 EPP..." in the Introduction section. 802 3. Reword the "The allocation token is known to the server..." 803 sentence in the Introduction section. 804 4. Modify the "The allocation token MAY be returned to an 805 authorized client for passing out-of-band to a client that 806 uses it with an EPP transform command" to clarify who the two 807 separate clients are. 808 5. Removed an unneeded ":" from the EPP Command and 809 EPP Command sections. 811 Authors' Addresses 813 James Gould 814 VeriSign, Inc. 815 12061 Bluemont Way 816 Reston, VA 20190 817 US 819 Email: jgould@verisign.com 820 URI: http://www.verisigninc.com 821 Kal Feher 822 Neustar 823 lvl 8/10 Queens Road 824 Melbourne, VIC 3004 825 AU 827 Email: kal.feher@team.neustar 828 URI: http://www.neustar.biz