idnits 2.17.1 draft-ietf-regext-allocation-token-12.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 (October 04, 2018) is 2002 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) No issues found here. Summary: 0 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: April 7, 2019 Neustar 6 October 04, 2018 8 Allocation Token Extension for the Extensible Provisioning Protocol 9 (EPP) 10 draft-ietf-regext-allocation-token-12 12 Abstract 14 This document describes an Extensible Provisioning Protocol (EPP) 15 extension for including an Allocation Token in "query" and 16 "transform" commands. The Allocation Token is used as a credential 17 that authorizes a client to request the allocation of a specific 18 object from the server, using one of the EPP transform commands 19 including create 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 https://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 April 7, 2019. 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . 4 58 2.1. Allocation Token . . . . . . . . . . . . . . . . . . . . 4 59 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 5 60 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 5 61 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 5 62 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 9 63 3.1.3. EPP Query Command . . . . . . . . . . . . 11 64 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 12 65 3.2.1. EPP Command . . . . . . . . . . . . . . . . 12 66 3.2.2. EPP Command . . . . . . . . . . . . . . . . 13 67 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 13 68 3.2.4. EPP Command . . . . . . . . . . . . . . . 13 69 3.2.5. EPP Command . . . . . . . . . . . . . . . . 14 70 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 71 4.1. Allocation Token Extension Schema . . . . . . . . . . . . 15 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 73 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 16 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 . . . . . . . . . . . . . . . . . . . . 18 79 6.4. Net::DRI . . . . . . . . . . . . . . . . . . . . . . . . 18 80 7. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 82 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 83 9.1. Normative References . . . . . . . . . . . . . . . . . . 19 84 9.2. Informative References . . . . . . . . . . . . . . . . . 20 85 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 20 86 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 20 87 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 20 88 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 21 89 A.4. Change from 03 to 04 . . . . . . . . . . . . . . . . . . 21 90 A.5. Change from 04 to REGEXT 00 . . . . . . . . . . . . . . . 21 91 A.6. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 21 92 A.7. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 21 93 A.8. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 21 94 A.9. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 21 95 A.10. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 21 96 A.11. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 22 97 A.12. Change from REGEXT 06 to REGEXT 07 . . . . . . . . . . . 23 98 A.13. Change from REGEXT 07 to REGEXT 08 . . . . . . . . . . . 23 99 A.14. Change from REGEXT 08 to REGEXT 09 . . . . . . . . . . . 24 100 A.15. Change from REGEXT 09 to REGEXT 10 . . . . . . . . . . . 24 101 A.16. Change from REGEXT 10 to REGEXT 11 . . . . . . . . . . . 25 102 A.17. Change from REGEXT 11 to REGEXT 12 . . . . . . . . . . . 26 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 105 1. Introduction 107 This document describes an extension mapping for version 1.0 of the 108 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping, an 109 extension to EPP object mappings like the EPP domain name mapping 110 [RFC5731], supports passing an Allocation Token as a credential that 111 authorizes a client to request the allocation of a specific object 112 from the server, using one of the EPP transform commands including 113 create and transfer. 115 Allocation is when a server assigns the sponsoring client of an 116 object based on the use of an Allocation Token credential. Examples 117 include allocating a registration based on a pre-eligibility 118 Allocation Token, allocating a premium domain name registration based 119 on an auction Allocation Token, allocating a registration based on a 120 founders Allocation Token, and allocating an existing domain name 121 held by the server or by a different sponsoring client based on an 122 Allocation Token passed with a transfer command. 124 Clients pass an Allocation Token to the server for validation, and 125 the server determines if the supplied Allocation Token is one 126 supported by the server. It is up to server policy which EPP 127 transform commands and which objects require the Allocation Token. 128 The Allocation Token MAY be returned to an authorized client for 129 passing out-of-band to a client that uses it with an EPP transform 130 command. 132 1.1. Conventions Used in This Document 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 136 "OPTIONAL" in this document are to be interpreted as described in BCP 137 14 [RFC2119] [RFC8174] when, and only when, they appear in all 138 capitals, as shown here. 140 XML is case sensitive. Unless stated otherwise, XML specifications 141 and examples provided in this document MUST be interpreted in the 142 character case presented in order to develop a conforming 143 implementation. 145 In examples, "C:" represents lines sent by a protocol client and "S:" 146 represents lines returned by a protocol server. Indentation and 147 white space in the examples are provided only to illustrate element 148 relationships and are not REQUIRED in the protocol. 150 The XML namespace prefix "allocationToken" is used for the namespace 151 "urn:ietf:params:xml:ns:allocationToken-1.0", but implementations 152 MUST NOT depend on it and instead employ a proper namespace-aware XML 153 parser and serializer to interpret and output the XML documents. 155 The "abc123" token value is used as a placeholder value in the 156 examples. The server MUST support token values that follow the 157 Security Considerations (Section 7) section. 159 The domain object attribute values, including the "2fooBAR" 160 value, in the examples are provided for illustration 161 purposes only. Refer to [RFC5731] for details on the domain object 162 attributes. 164 2. Object Attributes 166 This extension adds additional elements to EPP object mappings like 167 the EPP domain name mapping [RFC5731]. Only those new elements are 168 described here. 170 2.1. Allocation Token 172 The Allocation Token is a simple XML "token" type. The exact format 173 of the Allocation Token is up to server policy. The server MAY have 174 the Allocation Token for each object to match against the Allocation 175 Token passed by the client to authorize the allocation of the object. 176 The element is used for all of the 177 supported EPP commands as well as the info response. If the supplied 178 Allocation Token passed to the server does not apply to the object, 179 the server MUST return an EPP error result code of 2201. 181 Authorization information, like what is defined in the EPP domain 182 name mapping [RFC5731], is associated with objects to facilitate 183 transfer operations. The authorization information is assigned when 184 an object is created. The Allocation Token and the authorization 185 information are both credentials, but used for different purposes and 186 used in different ways. The Allocation Token is used to facilitate 187 the allocation of an object instead of transferring the sponsorship 188 of the object. The Allocation Token is not managed by the client, 189 but is validated by the server to authorize assigning the initial 190 sponsoring client of the object. 192 An example element with value of 193 "abc123": 195 197 abc123 198 200 3. EPP Command Mapping 202 A detailed description of the EPP syntax and semantics can be found 203 in the EPP core protocol specification [RFC5730]. 205 3.1. EPP Query Commands 207 EPP provides three commands to retrieve object information: 208 to determine if an object can be provisioned, to retrieve 209 information associated with an object, and to retrieve 210 object transfer status information. 212 3.1.1. EPP Command 214 This extension defines additional elements to extend the EPP 215 command of an object mapping like [RFC5731]. 217 This extension allows clients to check the availability of an object 218 with an Allocation Token, as described in Section 2.1. Clients can 219 check if an object can be created using the Allocation Token. The 220 Allocation Token is applied to all object names included in the EPP 221 command. 223 Example command for the allocation.example domain name using 224 the extension with the allocation 225 token of 'abc123': 227 C: 228 C: 229 C: 230 C: 231 C: 233 C: allocation.example 234 C: 235 C: 236 C: 237 C: 240 C: abc123 241 C: 242 C: 243 C: ABC-12345 244 C: 245 C: 247 If the query was successful, the server replies with a 248 response providing the availability status of the queried object 249 based on the following Allocation Token cases, where the object is 250 otherwise available: 252 1. If an object requires an Allocation Token and the Allocation 253 Token does apply to the object, then the server MUST return the 254 availability status as available (e.g., "avail" attribute is "1" 255 or "true"). 256 2. If an object requires an Allocation Token and the Allocation 257 Token does not apply to the object, then the server SHOULD return 258 the availability status as unavailable (e.g., "avail" attribute 259 is "0" or "false"). 260 3. If an object does not require an Allocation Token, the server MAY 261 return the availability status as available (e.g., "avail" 262 attribute is "1" or "true"). 264 Example domain response for a command using the 265 extension: 267 S: 268 S: 269 S: 270 S: 271 S: Command completed successfully 272 S: 273 S: 274 S: 276 S: 277 S: allocation.example 278 S: 279 S: 280 S: 281 S: 282 S: ABC-DEF-12345 283 S: 54321-XYZ 284 S: 285 S: 286 S: 287 Example command with the 288 extension for the allocation.example and allocation2.example domain 289 names. Availability of allocation.example and allocation2.example 290 domain names are based on the Allocation Token 'abc123': 292 C: 293 C: 294 C: 295 C: 296 C: 298 C: allocation.example 299 C: allocation2.example 300 C: 301 C: 302 C: 303 C: 306 C: abc123 307 C: 308 C: 309 C: ABC-DEF-12345 310 C: 311 C: 312 Example domain response for multiple domain names in the 313 command using the 314 extension, where the Allocation Token 'abc123' matches 315 allocation.example but does not match allocation2.example: 317 S: 318 S: 319 S: 320 S: 321 S: Command completed successfully 322 S: 323 S: 324 S: 326 S: 327 S: allocation.example 328 S: 329 S: 330 S: allocation2.example 331 S: Allocation Token mismatch 332 S: 333 S: 334 S: 335 S: 336 S: ABC-DEF-12345 337 S: 54321-XYZ 338 S: 339 S: 340 S: 342 This extension does not add any elements to the EPP response 343 described in the [RFC5730]. 345 3.1.2. EPP Command 347 This extension defines additional elements to extend the EPP 348 command of an object mapping like [RFC5731]. 350 The EPP command allows a client to request information 351 associated with an existing object. Authorized clients MAY retrieve 352 the Allocation Token (Section 2.1) along with the other object 353 information by supplying the element in the 354 command. The element is an empty element that 355 serves as a marker to the server to return the 356 element in the info response. If 357 the client is not authorized to receive the Allocation Token, the 358 server MUST return an EPP error result code of 2201. If the client 359 is authorized to receive the Allocation Token, but there is no 360 Allocation Token associated with the object, the server MUST return 361 an EPP error result code of 2303. The authorization is subject to 362 server policy. 364 Example command with the allocationToken:info extension for 365 the allocation.example domain name: 367 C: 368 C: 369 C: 370 C: 371 C: 375 C: allocation.example 376 C: 377 C: 378 C: 379 C: 382 C: 383 C: ABC-12345 384 C: 385 C: 387 If the query was successful, the server replies with an 388 element along with the regular EPP 389 . The element is 390 described in Section 2.1. 392 Example domain response using the 393 extension: 395 S: 396 S: 397 S: 398 S: 399 S: Command completed successfully 400 S: 401 S: 402 S: 404 S: allocation.example 405 S: EXAMPLE1-REP 406 S: 407 S: jd1234 408 S: sh8013 409 S: sh8013 410 S: ClientX 411 S: ClientY 412 S: 2012-04-03T22:00:00.0Z 413 S: 414 S: 2fooBAR 415 S: 416 S: 417 S: 418 S: 419 S: 422 S: abc123 423 S: 424 S: 425 S: 426 S: ABC-12345 427 S: 54321-XYZ 428 S: 429 S: 430 S: 432 3.1.3. EPP Query Command 434 This extension does not add any elements to the EPP query 435 command or query response described in [RFC5730]. 437 3.2. EPP Transform Commands 439 EPP provides five commands to transform objects: to create 440 an instance of an object, to delete an instance of an 441 object, to extend the validity period of an object, 442 to manage object sponsorship changes, and to 443 change information associated with an object. 445 3.2.1. EPP Command 447 This extension defines additional elements to extend the EPP 448 command of an object mapping like [RFC5731]. 450 The EPP command provides a transform operation that allows a 451 client to create an instance of an object. In addition to the EPP 452 command elements described in an object mapping like [RFC5731], the 453 command MUST contain a child 454 element for the client to be authorized to create and allocate the 455 object. If the Allocation Token does not apply to the object, the 456 server MUST return an EPP error result code of 2201. 458 Example command to create a domain object with an Allocation 459 Token: 461 C: 462 C: 463 C: 464 C: 465 C: 467 C: allocation.example 468 C: jd1234 469 C: sh8013 470 C: sh8013 471 C: 472 C: 2fooBAR 473 C: 474 C: 475 C: 476 C: 477 C: 480 C: abc123 481 C: 482 C: 483 C: ABC-12345 484 C: 485 C: 487 This extension does not add any elements to the EPP response 488 described in the [RFC5730]. 490 3.2.2. EPP Command 492 This extension does not add any elements to the EPP command 493 or response described in the [RFC5730]. 495 3.2.3. EPP Command 497 This extension does not add any elements to the EPP command 498 or response described in the [RFC5730]. 500 3.2.4. EPP Command 502 This extension defines additional elements to extend the EPP 503 request command of an object mapping like [RFC5731]. 505 The EPP request command provides a transform operation 506 that allows a client to request the transfer of an object. In 507 addition to the EPP command elements described in an object mapping 508 like [RFC5731], the command MUST contain a child 509 element for the client to be 510 authorized to transfer and allocate the object. The authorization 511 associated with the Allocation Token is in addition to and does not 512 replace the authorization mechanism defined for the object's 513 request command. If the Allocation Token is invalid or 514 not required for the object, the server MUST return an EPP error 515 result code of 2201. 517 Example request command to allocate the domain object with 518 the Allocation Token: 520 C: 521 C: 522 C: 523 C: 524 C: 526 C: example1.tld 527 C: 1 528 C: 529 C: 2fooBAR 530 C: 531 C: 532 C: 533 C: 534 C: 537 C: abc123 538 C: 539 C: 540 C: ABC-12345 541 C: 542 C: 544 This extension does not add any elements to the EPP 545 response described in the [RFC5730]. 547 3.2.5. EPP Command 549 This extension does not add any elements to the EPP command 550 or response described in the [RFC5730]. 552 4. Formal Syntax 554 One schema is presented here that is the EPP Allocation Token 555 Extension schema. 557 The formal syntax presented here is a complete schema representation 558 of the object mapping suitable for automated validation of EPP XML 559 instances. The BEGIN and END tags are not part of the schema; they 560 are used to note the beginning and ending of the schema for URI 561 registration purposes. 563 4.1. Allocation Token Extension Schema 565 BEGIN 566 567 571 572 573 Extensible Provisioning Protocol v1.0 574 Allocation Token Extension 575 576 578 579 580 581 582 583 584 585 587 589 591 592 593 594 595 597 598 599 END 601 5. IANA Considerations 603 5.1. XML Namespace 605 This document uses URNs to describe XML namespaces and XML schemas 606 conforming to a registry mechanism described in [RFC3688]. 608 Registration request for the allocationToken namespace: 610 URI: urn:ietf:params:xml:ns:allocationToken-1.0 611 Registrant Contact: IESG 612 XML: None. Namespace URIs do not represent an XML specification. 614 Registration request for the allocationToken XML schema: 616 URI: urn:ietf:params:xml:schema:allocationToken-1.0 617 Registrant Contact: IESG 618 XML: See the "Formal Syntax" section of this document. 620 5.2. EPP Extension Registry 622 The following registration of the EPP Extension Registry, described 623 in [RFC7451], is requested: 625 Name of Extension: "Allocation Token Extension for the Extensible 626 Provisioning Protocol (EPP)" 628 Document status: Standards Track 630 Reference: (insert reference to RFC version of this document) 632 Registrant Name and Email Address: IESG, 634 TLDs: Any 636 IPR Disclosure: None 638 Status: Active 640 Notes: None 642 6. Implementation Status 644 Note to RFC Editor: Please remove this section and the reference to 645 RFC 7942 [RFC7942] before publication. 647 This section records the status of known implementations of the 648 protocol defined by this specification at the time of posting of this 649 Internet-Draft, and is based on a proposal described in RFC 7942 650 [RFC7942]. The description of implementations in this section is 651 intended to assist the IETF in its decision processes in progressing 652 drafts to RFCs. Please note that the listing of any individual 653 implementation here does not imply endorsement by the IETF. 654 Furthermore, no effort has been spent to verify the information 655 presented here that was supplied by IETF contributors. This is not 656 intended as, and must not be construed to be, a catalog of available 657 implementations or their features. Readers are advised to note that 658 other implementations may exist. 660 According to RFC 7942 [RFC7942], "this will allow reviewers and 661 working groups to assign due consideration to documents that have the 662 benefit of running code, which may serve as evidence of valuable 663 experimentation and feedback that have made the implemented protocols 664 more mature. It is up to the individual working groups to use this 665 information as they see fit". 667 6.1. Verisign EPP SDK 669 Organization: Verisign Inc. 671 Name: Verisign EPP SDK 673 Description: The Verisign EPP SDK includes both a full client 674 implementation and a full server stub implementation of draft-ietf- 675 regext-allocation-token. 677 Level of maturity: Production 679 Coverage: All aspects of the protocol are implemented. 681 Licensing: GNU Lesser General Public License 683 Contact: jgould@verisign.com 685 URL: https://www.verisign.com/en_US/channel-resources/domain- 686 registry-products/epp-sdks 688 6.2. Neustar EPP SDK 690 Organisation: Neustar Inc. 692 Name: Neustar EPP SDK 694 Description: The Neustar EPP SDK includes a full client 695 implementation of draft-ietf-regext-allocation-token. 697 Level of maturity: Production 699 Coverage: All aspects of the protocol are implemented. 701 Licensing: GNU Lesser General Public License 703 Contact: quoc-anh.np@team.neustar 705 URL: http://registrytoolkit.neustar 707 6.3. Neustar gTLD SRS 709 Organisation: Neustar Inc. 711 Name: Neustar generic Top Level Domain (gTLD) Shared Registry System 712 (SRS). 714 Description: The Neustar gTLD SRS implements the server side of 715 draft-ietf-regext-allocation-token for several Top Level Domains. 717 Level of maturity: Production 719 Coverage: All server side aspects of the protocol are implemented. 721 Licensing: Proprietary 723 Contact: quoc-anh.np@team.neustar 725 6.4. Net::DRI 727 Organization: Dot and Co 729 Name: Net::DRI 731 Description: Net::DRI implements the client-side of draft-ietf- 732 regext-allocation-token. 734 Level of maturity: Production 736 Coverage: All client-side aspects of the protocol are implemented. 738 Licensing: GNU Lesser General Public License 740 Contact: netdri@dotandco.com 742 7. Security Considerations 744 The mapping described in this document does not provide any security 745 services beyond those described by EPP [RFC5730] and protocol layers 746 used by EPP. The security considerations described in these other 747 specifications apply to this specification as well. 749 The mapping acts as a conduit for the passing of Allocation Tokens 750 between a client and a server. The definition of the Allocation 751 Token SHOULD be defined outside of this mapping. The following are 752 security considerations in the definition and use of an Allocation 753 Token: 755 1. An Allocation Token should be considered secret information by 756 the client and SHOULD be protected at rest and MUST be protected 757 in transit. 758 2. An Allocation Token should be single use, meaning it should be 759 unique per object and per allocation operation. 760 3. An Allocation Token should have a limited life with some form of 761 expiry in the Allocation Token if generated by a trusted 3rd 762 third party, or with a server-side expiry if generated by the 763 server. 764 4. An Allocation Token should use a strong random value if it is 765 based on an unsigned code. 766 5. An Allocation Token should leverage digital signatures to confirm 767 its authenticity if generated by a trusted 3rd party. 768 6. An Allocation Token that is signed XML should be encoded (e.g., 769 base64 [RFC4648]) to mitigate server validation issues. 771 8. Acknowledgements 773 The authors wish to acknowledge the original concept for this draft 774 and the efforts in the initial versions of this draft by Trung Tran 775 and Sharon Wodjenski. 777 Special suggestions that have been incorporated into this document 778 were provided by Ben Campbell, Scott Hollenbeck, Benjamin Kaduk, 779 Mirja Kuehlewind, Rubens Kuhl, Alexander Mayrhofer, Patrick Mevzek, 780 Eric Rescoria, and Adam Roach. 782 9. References 784 9.1. Normative References 786 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 787 Requirement Levels", BCP 14, RFC 2119, 788 DOI 10.17487/RFC2119, March 1997, 789 . 791 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 792 DOI 10.17487/RFC3688, January 2004, 793 . 795 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 796 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 797 . 799 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 800 Domain Name Mapping", STD 69, RFC 5731, 801 DOI 10.17487/RFC5731, August 2009, 802 . 804 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 805 Code: The Implementation Status Section", BCP 205, 806 RFC 7942, DOI 10.17487/RFC7942, July 2016, 807 . 809 9.2. Informative References 811 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data 812 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006, 813 . 815 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 816 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 817 February 2015, . 819 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 820 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 821 May 2017, . 823 Appendix A. Change History 825 A.1. Change from 00 to 01 827 1. Amended XML Namespace section of IANA Considerations, added EPP 828 Extension Registry section. 829 2. Moved Change History to the back section as an Appendix. 831 A.2. Change from 01 to 02 833 1. Ping update. 835 A.3. Change from 02 to 03 837 1. Ping update. 839 A.4. Change from 03 to 04 841 1. Updated the authors for the draft. 843 A.5. Change from 04 to REGEXT 00 845 1. Changed to regext working group draft by changing draft-gould- 846 allocation-token to draft-ietf-regext-allocation-token. 848 A.6. Change from REGEXT 00 to REGEXT 01 850 1. Ping update. 852 A.7. Change from REGEXT 01 to REGEXT 02 854 1. Added the Implementation Status section. 856 A.8. Change from REGEXT 02 to REGEXT 03 858 1. Changed Neustar author to Kal Feher. 860 A.9. Change from REGEXT 03 to REGEXT 04 862 1. Added Neustar implementation to the Implementation Status 863 section. 865 A.10. Change from REGEXT 04 to REGEXT 05 867 1. Updates based on feedback from Patrick Mevzek, that include: 869 1. Remove "or code" from the Abstract section. 870 2. Add a missing "to" in "an allocation token TO one of the 871 EPP..." in the Introduction section. 872 3. Reword the "The allocation token is known to the server..." 873 sentence in the Introduction section. 874 4. Modify the "The allocation token MAY be returned to an 875 authorized client for passing out-of-band to a client that 876 uses it with an EPP transform command" to clarify who the two 877 separate clients are. 878 5. Removed an unneeded ":" from the EPP Command and 879 EPP Command sections. 881 A.11. Change from REGEXT 05 to REGEXT 06 883 1. Fix description of Neustar gTLD SRS based on feedback from Rubens 884 Kuhl. 885 2. Updates based on feedback from Alexander Mayrhofer, that include: 887 1. Making all references to Allocation Token to use the upper 888 case form. 889 2. Revise the language of the abstract to include "for 890 including an Allocation Token in query and transform 891 commands. The Allocation Token is used as a credential that 892 authorizes a client to request the allocation of a specific 893 object from the server, using one of the EPP transform 894 commands..." 895 3. Replace the title "EPP Command" with "EPP 896 Query Command" for section 3.1.3. 897 4. Revise the second sentence of the Introduction to "The 898 mapping, ..., supports passing an Allocation Token..." 899 5. Change "support" to "require" in the Introduction sentence 900 "It is up to server policy which EPP transform commands and 901 which objects support the Allocation Token." 902 6. Add the definition of Allocation to the Introduction. 903 7. Removed "transform" from "all of the supported EPP transform 904 commands" in the "Allocation Token" section, since the 905 Allocation Token can be used with the "check" command as 906 well. 907 8. Remove the word "same" from "The same 908 element is used for 909 all..." in the "Allocation Token" section. 910 9. Change the description of the use of the 2201 error in the 911 "Allocation Token" section, the "EPP Command" 912 section, the "EPP Command" section, and the "EPP 913 Command" section. 914 10. Revise " to determine if an object is known to the 915 server..." to " to determine if an object can be 916 provisioned..." and remove "detailed" in the description of 917 the in the "EPP Query Commands" section. 918 11. Add missing description of the expected response 919 behavior. 920 12. Replaced the example reason "Invalid domain-token pair" with 921 "Allocation Token mismatch". 922 13. Replace "information on" with "information associated with" 923 in the "EPP Command" section. 924 14. Removed the "that identifies the extension namespace", the 925 ", defined in...", the Allocation Token links from the error 926 response sentences, and the "object referencing the 927 element" in the "EPP Command" 928 section. 930 15. Added "The authorization is subject to server policy." to 931 the "EPP Command" section. 932 16. Replace "or response>" with "or query 933 response>" in the EPP Query Command" section. 934 17. Replace "create an object" with "create an instance of an 935 object" in the "EPP Command" section. 936 18. Revised the sentence to include "the command MUST contain a 937 child element for the 938 client to be authorized to create and allocate the object" 939 in the "EPP Command" section. 940 19. Removed the reference to section 2.1 and the namespace 941 identification text in the "EPP Command" section. 942 20. Added "The authorization associated with the Allocation 943 Token is in addition to and does not replace the 944 authorization mechanism defined for the object's 945 request command." to the "EPP Command" section. 946 21. Modified the first sentence of the "EPP Extension Registry" 947 section to read "The following registration of the EPP 948 Extension Registry, described in RFC7451, is requested" 949 22. Removed support with using the Allocation Token with an 950 empty extension of update (e.g., release command), based on 951 the confusion and lack of known applicability. 952 3. Updates based on feedback from Scott Hollenbeck, that include: 954 1. Revised XML schema to included a minimum length of 1 for the 955 allocationTokenType. 956 2. Revised the "IANA Considerations" section to include the 957 registration of the XML schema. 958 3. Revised the "Security Considerations" section to include 959 considerations for the definition of the Allocation Tokens. 961 A.12. Change from REGEXT 06 to REGEXT 07 963 1. Updates based on feedback from Patrick Mevzek: 965 1. Updated obsoleted RFC 7942 to RFC 7942. 966 2. Moved RFC 7451 to an informational reference. 968 A.13. Change from REGEXT 07 to REGEXT 08 970 1. Changed Kal Feher's contact e-mail address. 971 2. Changed Neustar's Implementation Status contact e-mail address. 972 3. Added the Net::DRI sub-section to the Implementation Status 973 section. 975 A.14. Change from REGEXT 08 to REGEXT 09 977 1. Updates based on the AD review by Adam Roach, that include: 979 1. In "Abstract", set "query" and "transform" off in some way 980 (e.g., using quotation marks) 981 2. In "Conventions Used in This Document", please update to use 982 the boilerplate from RFC 8174. 983 3. Remove "allocationToken-1.0" is used as an abbreviation for 984 "urn:ietf:params:xml:ns:allocationToken-1.0". 985 4. In "Allocation Token", change "The server MUST have the 986 Allocation Token" to "The server MAY have the Allocation 987 Token". 988 5. In "EPP Command", change "This extension allow 989 clients" to "This extension allows clients". 990 6. Use domains reserved by RFC 2026 for the examples. The 991 example domain "example.tld" was changed to 992 "allocation.example" and the example domain "example2.tld" 993 was changed to "allocation2.example". 994 7. In "EPP Command", change "...the server MUST return 995 an EPP error result code of 2303 object referencing the 996 element." to "...the server MUST 997 return an EPP error result code of 2303." 998 8. In "EPP Query Command", remove "the" before 999 "RFC5730". 1000 9. In "EPP Command", change "If the Allocation Token 1001 does not apply to the object..." to "If the Allocation Token 1002 is invalid or not required for the object...". 1003 10. In "XML Namespace", remove the sentence "The following URI 1004 assignment is requested of IANA:" 1005 11. In "Security Considerations", change "An Allocation Token 1006 should is" to "An Allocation Token that is". Also 1007 informatively cite RFC 4648 for the base64 reference. 1008 2. Change "ietf:params:xml:ns:allocationToken-1.0" to 1009 "ietf:params:xml:schema:allocationToken-1.0" for the XML schema 1010 IANA registration. 1012 A.15. Change from REGEXT 09 to REGEXT 10 1014 1. Changed "auhorization" to "authorization" in the "EPP 1015 Command" section. 1016 2. Added 'If an object does not require an Allocation Token, the 1017 server MAY return the availability status as available (e.g., 1018 "avail" attribute is "1" or "true").' to the check response 1019 cases, based on feedback by Mirja Kuehlewind. 1020 3. Changed the definition of the element in the XML schema to 1021 only allow an empty element, based on IANA's expert review. 1023 4. Added normative language to the storage and transport of the 1024 Allocation Token, in the "Security Considerations" section, based 1025 on feedback from Eric Rescoria. 1026 5. Changed "The definition of the Allocation Token is defined 1027 outside of this mapping" to "The definition of the Allocation 1028 Token SHOULD be defined outside of this mapping", in the 1029 "Security Considerations" section, based on feedback from Eric 1030 Rescoria. 1031 6. Added the missing "urn:" prefix with the IANA URI registrations. 1032 7. The URL for the BCP 14 was removed based on feedback from Alissa 1033 Cooper. 1034 8. Updates based on review by Benjamin Kaduk, that include: 1036 1. Added the second paragraph to the "Allocation Token" section 1037 to describe the difference (motivation) of using the 1038 Allocation Token versus the EPP RFC authorization mechanism. 1039 2. Added a paragraph to the "Conventions Used in This Document" 1040 section for the use of the "abc123" token value and the use 1041 of domain object "2fooBAR" password value in the examples. 1042 3. Changed the "A client MUST pass an Allocation Token known to 1043 the server to be authorized to use one of the supported EPP 1044 transform commands." sentence in the "Introduction" section 1045 to "Clients pass an Allocation Token to the server for 1046 validation, and the server determines if the supplied 1047 Allocation Token is one supported by the server." 1048 4. Changed the "Indentation and white space in the examples are 1049 provided only to illustrate element relationships and are not 1050 REQUIRED in the protocol." sentence in the "Conventions Used 1051 in This Document" section to "Indentation and white space in 1052 the examples are provided only to illustrate element 1053 relationships and are not REQUIRED in the protocol." 1054 5. Changed the "Authorized clients MAY retrieve..." sentence in 1055 the "EPP Command" section. 1056 6. Changed the "If the query was successful..." sentence in the 1057 "EPP Command" section. 1058 7. Added "supplied" to the "If the supplied Allocation Token 1059 passed..." sentence in the "Allocation Token" section. 1060 8. Removed an extra newline in the element in the 1061 "Allocation Token Extension Schema" section. 1063 A.16. Change from REGEXT 10 to REGEXT 11 1065 1. Removed the old duplicate "Authorized clients MAY retrieve..." 1066 sentence from section 3.1.2 "EPP Command". 1068 A.17. Change from REGEXT 11 to REGEXT 12 1070 1. Revised the example domain response to first include the 1071 positive case for allocation.example, and to second include the 1072 negative case for allocation2.example, based on feedback from Ben 1073 Campbell. The caption was revised for the example to include the 1074 text ", where the Allocation Token 'abc123' matches 1075 allocation.example but does not match allocation2.example". 1077 Authors' Addresses 1079 James Gould 1080 VeriSign, Inc. 1081 12061 Bluemont Way 1082 Reston, VA 20190 1083 US 1085 Email: jgould@verisign.com 1086 URI: http://www.verisigninc.com 1088 Kal Feher 1089 Neustar 1090 lvl 8/10 Queens Road 1091 Melbourne, VIC 3004 1092 AU 1094 Email: ietf@feherfamily.org 1095 URI: http://www.neustar.biz