1 Internet Engineering Task Force (IETF) J. Gould
2 Request for Comments: 8495 VeriSign, Inc.
3 Category: Standards Track K. Feher
4 ISSN: 2070-1721 Neustar
5 November 2018
6
7
8 Allocation Token Extension
9 for the Extensible Provisioning Protocol (EPP)
10
11 Abstract
12
13 This document describes an Extensible Provisioning Protocol (EPP)
14 extension for including an Allocation Token in "query" and
15 "transform" commands. The Allocation Token is used as a credential
16 that authorizes a client to request the allocation of a specific
17 object from the server using one of the EPP transform commands,
18 including "create" and "transfer".
19
20 Status of This Memo
21
22 This is an Internet Standards Track document.
23
24 This document is a product of the Internet Engineering Task Force
25 (IETF). It represents the consensus of the IETF community. It has
26 received public review and has been approved for publication by the
27 Internet Engineering Steering Group (IESG). Further information on
28 Internet Standards is available in Section 2 of RFC 7841.
29
30 Information about the current status of this document, any errata,
31 and how to provide feedback on it may be obtained at
32 https://www.rfc-editor.org/info/rfc8495.
33
34 Copyright Notice
35
36 Copyright (c) 2018 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
38
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (https://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
48
49
50
51
52 Gould & Feher Standards Track [Page 1]
53 RFC 8495 Allocation Token November 2018
54
55
56 Table of Contents
57
58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
59 1.1. Conventions Used in This Document . . . . . . . . . . . . 3
60 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3
61 2.1. Allocation Token . . . . . . . . . . . . . . . . . . . . 4
62 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 4
63 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 4
64 3.1.1. EPP <check> Command . . . . . . . . . . . . . . . . . 4
65 3.1.2. EPP <info> Command . . . . . . . . . . . . . . . . . 8
66 3.1.3. EPP <transfer> Query Command . . . . . . . . . . . . 10
67 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 11
68 3.2.1. EPP <create> Command . . . . . . . . . . . . . . . . 11
69 3.2.2. EPP <delete> Command . . . . . . . . . . . . . . . . 12
70 3.2.3. EPP <renew> Command . . . . . . . . . . . . . . . . . 12
71 3.2.4. EPP <transfer> Command . . . . . . . . . . . . . . . 12
72 3.2.5. EPP <update> Command . . . . . . . . . . . . . . . . 13
73 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14
74 4.1. Allocation Token Extension Schema . . . . . . . . . . . . 14
75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
76 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 15
77 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 15
78 6. Security Considerations . . . . . . . . . . . . . . . . . . . 15
79 7. References . . . . . . . . . . . . . . . . . . . . . . . . . 16
80 7.1. Normative References . . . . . . . . . . . . . . . . . . 16
81 7.2. Informative References . . . . . . . . . . . . . . . . . 17
82 Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 17
84
85 1. Introduction
86
87 This document describes an extension mapping for version 1.0 of the
88 Extensible Provisioning Protocol (EPP) [RFC5730]. This mapping,
89 which is an extension to EPP object mappings similar to the EPP
90 domain name mapping [RFC5731], supports passing an Allocation Token
91 as a credential that authorizes a client to request the allocation of
92 a specific object from the server using one of the EPP transform
93 commands, including "create" and "transfer".
94
95 Allocation is when a server assigns the sponsoring client of an
96 object based on the use of an Allocation Token credential. Examples
97 include allocating a registration based on a pre-eligibility
98 Allocation Token, allocating a premium domain name registration based
99 on an auction Allocation Token, allocating a registration based on a
100 founders Allocation Token, and allocating an existing domain name
101 held by the server or by a different sponsoring client based on an
102 Allocation Token that is passed with a transfer command.
103
104
105
106
107 Gould & Feher Standards Track [Page 2]
108 RFC 8495 Allocation Token November 2018
109
110
111 Clients pass an Allocation Token to the server for validation, and
112 the server determines if the supplied Allocation Token is one
113 supported by the server. It is up to server policy which EPP
114 transform commands and which objects require the Allocation Token.
115 The Allocation Token MAY be returned to an authorized client for
116 passing out-of-band to a client that uses it with an EPP transform
117 command.
118
119 1.1. Conventions Used in This Document
120
121 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
122 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
123 "OPTIONAL" in this document are to be interpreted as described in
124 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
125 capitals, as shown here.
126
127 XML is case sensitive. Unless stated otherwise, XML specifications
128 and examples provided in this document MUST be interpreted in the
129 character case presented in order to develop a conforming
130 implementation.
131
132 In examples, "C:" represents lines sent by a protocol client and "S:"
133 represents lines returned by a protocol server. Indentation and
134 white space in the examples are provided only to illustrate element
135 relationships and are not REQUIRED in the protocol.
136
137 The XML namespace prefix "allocationToken" is used for the namespace
138 "urn:ietf:params:xml:ns:allocationToken-1.0", but implementations
139 MUST NOT depend on it and instead employ a proper namespace-aware XML
140 parser and serializer to interpret and output the XML documents.
141
142 The "abc123" token value is used as a placeholder value in the
143 examples. The server MUST support token values that follow the
144 Security Considerations (Section 6).
145
146 The domain-object attribute values, including the "2fooBAR"
147 <domain:pw> value, in the examples are provided for illustration
148 purposes only. Refer to [RFC5731] for details on the domain-object
149 attributes.
150
151 2. Object Attributes
152
153 This extension adds additional elements to EPP object mappings
154 similar to the EPP domain name mapping [RFC5731]. Only those new
155 elements are described here.
156
157
158
159
160
161
162 Gould & Feher Standards Track [Page 3]
163 RFC 8495 Allocation Token November 2018
164
165
166 2.1. Allocation Token
167
168 The Allocation Token is a simple XML "token" type. The exact format
169 of the Allocation Token is up to server policy. The server MAY have
170 the Allocation Token for each object to match against the Allocation
171 Token passed by the client to authorize the allocation of the object.
172 The <allocationToken:allocationToken> element is used for all of the
173 supported EPP commands as well as the info response. If the supplied
174 Allocation Token passed to the server does not apply to the object,
175 the server MUST return an EPP error result code of 2201.
176
177 Authorization information, similar to what is defined in the EPP
178 domain name mapping [RFC5731], is associated with objects to
179 facilitate transfer operations. The authorization information is
180 assigned when an object is created. The Allocation Token and the
181 authorization information are both credentials but are used for
182 different purposes and in different ways. The Allocation Token is
183 used to facilitate the allocation of an object instead of
184 transferring the sponsorship of the object. The Allocation Token is
185 not managed by the client but is validated by the server to authorize
186 assigning the initial sponsoring client of the object.
187
188 An example <allocationToken:allocationToken> element with value of
189 "abc123":
190
191 <allocationToken:allocationToken xmlns:allocationToken=
192 "urn:ietf:params:xml:ns:allocationToken-1.0">
193 abc123
194 </allocationToken:allocationToken>
195
196 3. EPP Command Mapping
197
198 A detailed description of the EPP syntax and semantics can be found
199 in the EPP core protocol specification [RFC5730].
200
201 3.1. EPP Query Commands
202
203 EPP provides three commands to retrieve object information: <check>
204 to determine if an object can be provisioned, <info> to retrieve
205 information associated with an object, and <transfer> to retrieve
206 object-transfer status information.
207
208 3.1.1. EPP <check> Command
209
210 This extension defines additional elements to extend the EPP <check>
211 command of an object mapping similar to the mapping specified in
212 [RFC5731].
213
214
215
216
217 Gould & Feher Standards Track [Page 4]
218 RFC 8495 Allocation Token November 2018
219
220
221 This extension allows clients to check the availability of an object
222 with an Allocation Token, as described in Section 2.1. Clients can
223 check if an object can be created using the Allocation Token. The
224 Allocation Token is applied to all object names included in the EPP
225 <check> command.
226
227 The following is an example <check> command for the
228 allocation.example domain name using the
229 <allocationToken:allocationToken> extension with the allocation token
230 of 'abc123':
231
232 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
233 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
234 C: <command>
235 C: <check>
236 C: <domain:check
237 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
238 C: <domain:name>allocation.example</domain:name>
239 C: </domain:check>
240 C: </check>
241 C: <extension>
242 C: <allocationToken:allocationToken
243 C: xmlns:allocationToken=
244 C: "urn:ietf:params:xml:ns:allocationToken-1.0">
245 C: abc123
246 C: </allocationToken:allocationToken>
247 C: </extension>
248 C: <clTRID>ABC-12345</clTRID>
249 C: </command>
250 C:</epp>
251
252 If the query was successful, the server replies with a <check>
253 response providing the availability status of the queried object
254 based on the following Allocation Token cases where the object is
255 otherwise available:
256
257 1. If an object requires an Allocation Token and the Allocation
258 Token does apply to the object, then the server MUST return the
259 availability status as available (e.g., the "avail" attribute is
260 "1" or "true").
261 2. If an object requires an Allocation Token and the Allocation
262 Token does not apply to the object, then the server SHOULD return
263 the availability status as unavailable (e.g., the "avail"
264 attribute is "0" or "false").
265 3. If an object does not require an Allocation Token, the server MAY
266 return the availability status as available (e.g., the "avail"
267 attribute is "1" or "true").
268
269
270
271
272 Gould & Feher Standards Track [Page 5]
273 RFC 8495 Allocation Token November 2018
274
275
276 The following is an example <check> domain response for a <check>
277 command using the <allocationToken:allocationToken> extension:
278
279 S:<?xml version="1.0" encoding="UTF-8"?>
280 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
281 S: <response>
282 S: <result code="1000">
283 S: <msg lang="en-US">Command completed successfully</msg>
284 S: </result>
285 S: <resData>
286 S: <domain:chkData
287 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
288 S: <domain:cd>
289 S: <domain:name avail="1">allocation.example</domain:name>
290 S: </domain:cd>
291 S: </domain:chkData>
292 S: </resData>
293 S: <trID>
294 S: <clTRID>ABC-DEF-12345</clTRID>
295 S: <svTRID>54321-XYZ</svTRID>
296 S: </trID>
297 S: </response>
298 S:</epp>
299
300
301
302
303
304
305
306
307
308
309
310
311
312
313
314
315
316
317
318
319
320
321
322
323
324
325
326
327 Gould & Feher Standards Track [Page 6]
328 RFC 8495 Allocation Token November 2018
329
330
331 The following is an example <check> command with the
332 <allocationToken:allocationToken> extension for the
333 allocation.example and allocation2.example domain names.
334 Availability of allocation.example and allocation2.example domain
335 names are based on the Allocation Token 'abc123':
336
337 C:<?xml version="1.0" encoding="UTF-8"?>
338 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
339 C: <command>
340 C: <check>
341 C: <domain:check
342 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
343 C: <domain:name>allocation.example</domain:name>
344 C: <domain:name>allocation2.example</domain:name>
345 C: </domain:check>
346 C: </check>
347 C: <extension>
348 C: <allocationToken:allocationToken
349 C: xmlns:allocationToken=
350 C: "urn:ietf:params:xml:ns:allocationToken-1.0">
351 C: abc123
352 C: </allocationToken:allocationToken>
353 C: </extension>
354 C: <clTRID>ABC-DEF-12345</clTRID>
355 C: </command>
356 C:</epp>
357
358
359
360
361
362
363
364
365
366
367
368
369
370
371
372
373
374
375
376
377
378
379
380
381
382 Gould & Feher Standards Track [Page 7]
383 RFC 8495 Allocation Token November 2018
384
385
386 The following is an example <check> domain response for multiple
387 domain names in the <check> command using the
388 <allocationToken:allocationToken> extension, where the Allocation
389 Token 'abc123' matches allocation.example but does not match
390 allocation2.example:
391
392 S:<?xml version="1.0" encoding="UTF-8"?>
393 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
394 S: <response>
395 S: <result code="1000">
396 S: <msg lang="en-US">Command completed successfully</msg>
397 S: </result>
398 S: <resData>
399 S: <domain:chkData
400 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
401 S: <domain:cd>
402 S: <domain:name avail="1">allocation.example</domain:name>
403 S: </domain:cd>
404 S: <domain:cd>
405 S: <domain:name avail="0">allocation2.example</domain:name>
406 S: <domain:reason>Allocation Token mismatch</domain:reason>
407 S: </domain:cd>
408 S: </domain:chkData>
409 S: </resData>
410 S: <trID>
411 S: <clTRID>ABC-DEF-12345</clTRID>
412 S: <svTRID>54321-XYZ</svTRID>
413 S: </trID>
414 S: </response>
415 S:</epp>
416
417 This extension does not add any elements to the EPP <check> response
418 described in [RFC5730].
419
420 3.1.2. EPP <info> Command
421
422 This extension defines additional elements to extend the EPP <info>
423 command of an object mapping similar to the mapping specified in
424 [RFC5731].
425
426 The EPP <info> command allows a client to request information
427 associated with an existing object. Authorized clients MAY retrieve
428 the Allocation Token (Section 2.1) along with the other object
429 information by supplying the <allocationToken:info> element in the
430 command. The <allocationToken:info> element is an empty element that
431 serves as a marker to the server to return the
432 <allocationToken:allocationToken> element in the info response. If
433 the client is not authorized to receive the Allocation Token, the
434
435
436
437 Gould & Feher Standards Track [Page 8]
438 RFC 8495 Allocation Token November 2018
439
440
441 server MUST return an EPP error result code of 2201. If the client
442 is authorized to receive the Allocation Token, but there is no
443 Allocation Token associated with the object, the server MUST return
444 an EPP error result code of 2303. The authorization is subject to
445 server policy.
446
447 The following is an example <info> command with the
448 allocationToken:info extension for the allocation.example domain
449 name:
450
451 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
452 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
453 C: <command>
454 C: <info>
455 C: <domain:info
456 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
457 C: <domain:name>allocation.example</domain:name>
458 C: </domain:info>
459 C: </info>
460 C: <extension>
461 C: <allocationToken:info
462 C: xmlns:allocationToken=
463 C: "urn:ietf:params:xml:ns:allocationToken-1.0"/>
464 C: </extension>
465 C: <clTRID>ABC-12345</clTRID>
466 C: </command>
467 C:</epp>
468
469 If the query was successful, the server replies with an
470 <allocationToken:allocationToken> element along with the regular EPP
471 <resData>. The <allocationToken:allocationToken> element is
472 described in Section 2.1.
473
474
475
476
477
478
479
480
481
482
483
484
485
486
487
488
489
490
491
492 Gould & Feher Standards Track [Page 9]
493 RFC 8495 Allocation Token November 2018
494
495
496 The following is an example <info> domain response using the
497 <allocationToken:allocationToken> extension:
498
499 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
500 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
501 S: <response>
502 S: <result code="1000">
503 S: <msg>Command completed successfully</msg>
504 S: </result>
505 S: <resData>
506 S: <domain:infData
507 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
508 S: <domain:name>allocation.example</domain:name>
509 S: <domain:roid>EXAMPLE1-REP</domain:roid>
510 S: <domain:status s="pendingCreate"/>
511 S: <domain:registrant>jd1234</domain:registrant>
512 S: <domain:contact type="admin">sh8013</domain:contact>
513 S: <domain:contact type="tech">sh8013</domain:contact>
514 S: <domain:clID>ClientX</domain:clID>
515 S: <domain:crID>ClientY</domain:crID>
516 S: <domain:crDate>2012-04-03T22:00:00.0Z</domain:crDate>
517 S: <domain:authInfo>
518 S: <domain:pw>2fooBAR</domain:pw>
519 S: </domain:authInfo>
520 S: </domain:infData>
521 S: </resData>
522 S: <extension>
523 S: <allocationToken:allocationToken
524 S: xmlns:allocationToken=
525 S: "urn:ietf:params:xml:ns:allocationToken-1.0">
526 S: abc123
527 S: </allocationToken:allocationToken>
528 S: </extension>
529 S: <trID>
530 S: <clTRID>ABC-12345</clTRID>
531 S: <svTRID>54321-XYZ</svTRID>
532 S: </trID>
533 S: </response>
534 S:</epp>
535
536 3.1.3. EPP <transfer> Query Command
537
538 This extension does not add any elements to the EPP <transfer> query
539 command or <transfer> query response described in [RFC5730].
540
541
542
543
544
545
546
547 Gould & Feher Standards Track [Page 10]
548 RFC 8495 Allocation Token November 2018
549
550
551 3.2. EPP Transform Commands
552
553 EPP provides five commands to transform objects: <create> to create
554 an instance of an object, <delete> to delete an instance of an
555 object, <renew> to extend the validity period of an object,
556 <transfer> to manage object sponsorship changes, and <update> to
557 change information associated with an object.
558
559 3.2.1. EPP <create> Command
560
561 This extension defines additional elements to extend the EPP <create>
562 command of an object mapping similar to the mapping specified in
563 [RFC5731].
564
565 The EPP <create> command provides a transform operation that allows a
566 client to create an instance of an object. In addition to the EPP
567 command elements described in an object mapping similar to the
568 mapping specified in [RFC5731], the command MUST contain a child
569 <allocationToken:allocationToken> element for the client to be
570 authorized to create and allocate the object. If the Allocation
571 Token does not apply to the object, the server MUST return an EPP
572 error result code of 2201.
573
574
575
576
577
578
579
580
581
582
583
584
585
586
587
588
589
590
591
592
593
594
595
596
597
598
599
600
601
602 Gould & Feher Standards Track [Page 11]
603 RFC 8495 Allocation Token November 2018
604
605
606 The following is an example <create> command to create a domain
607 object with an Allocation Token:
608
609 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
610 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
611 C: <command>
612 C: <create>
613 C: <domain:create
614 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
615 C: <domain:name>allocation.example</domain:name>
616 C: <domain:registrant>jd1234</domain:registrant>
617 C: <domain:contact type="admin">sh8013</domain:contact>
618 C: <domain:contact type="tech">sh8013</domain:contact>
619 C: <domain:authInfo>
620 C: <domain:pw>2fooBAR</domain:pw>
621 C: </domain:authInfo>
622 C: </domain:create>
623 C: </create>
624 C: <extension>
625 C: <allocationToken:allocationToken
626 C: xmlns:allocationToken=
627 C: "urn:ietf:params:xml:ns:allocationToken-1.0">
628 C: abc123
629 C: </allocationToken:allocationToken>
630 C: </extension>
631 C: <clTRID>ABC-12345</clTRID>
632 C: </command>
633 C:</epp>
634
635 This extension does not add any elements to the EPP <create> response
636 described in [RFC5730].
637
638 3.2.2. EPP <delete> Command
639
640 This extension does not add any elements to the EPP <delete> command
641 or <delete> response described in [RFC5730].
642
643 3.2.3. EPP <renew> Command
644
645 This extension does not add any elements to the EPP <renew> command
646 or <renew> response described in [RFC5730].
647
648 3.2.4. EPP <transfer> Command
649
650 This extension defines additional elements to extend the EPP
651 <transfer> command of an object mapping similar to the mapping
652 specified in [RFC5731].
653
654
655
656
657 Gould & Feher Standards Track [Page 12]
658 RFC 8495 Allocation Token November 2018
659
660
661 The EPP <transfer> command provides a transform operation that allows
662 a client to request the transfer of an object. In addition to the
663 EPP command elements described in an object mapping similar to the
664 mapping specified in [RFC5731], the command MUST contain a child
665 <allocationToken:allocationToken> element for the client to be
666 authorized to transfer and allocate the object. The authorization
667 associated with the Allocation Token is in addition to, and does not
668 replace, the authorization mechanism defined for the object's
669 <transfer> command. If the Allocation Token is invalid or not
670 required for the object, the server MUST return an EPP error result
671 code of 2201.
672
673 The following is an example <transfer> command to allocate the domain
674 object with the Allocation Token:
675
676 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
677 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
678 C: <command>
679 C: <transfer op="request">
680 C: <domain:transfer
681 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
682 C: <domain:name>example1.tld</domain:name>
683 C: <domain:period unit="y">1</domain:period>
684 C: <domain:authInfo>
685 C: <domain:pw>2fooBAR</domain:pw>
686 C: </domain:authInfo>
687 C: </domain:transfer>
688 C: </transfer>
689 C: <extension>
690 C: <allocationToken:allocationToken
691 C: xmlns:allocationToken=
692 C: "urn:ietf:params:xml:ns:allocationToken-1.0">
693 C: abc123
694 C: </allocationToken:allocationToken>
695 C: </extension>
696 C: <clTRID>ABC-12345</clTRID>
697 C: </command>
698 C:</epp>
699
700 This extension does not add any elements to the EPP <transfer>
701 response described in [RFC5730].
702
703 3.2.5. EPP <update> Command
704
705 This extension does not add any elements to the EPP <update> command
706 or <update> response described in [RFC5730].
707
708
709
710
711
712 Gould & Feher Standards Track [Page 13]
713 RFC 8495 Allocation Token November 2018
714
715
716 4. Formal Syntax
717
718 One schema is presented here: the EPP Allocation Token Extension
719 schema.
720
721 The formal syntax presented here is a complete schema representation
722 of the object mapping suitable for automated validation of EPP XML
723 instances. The BEGIN and END tags are not part of the schema; they
724 are used to note the beginning and ending of the schema for URI
725 registration purposes.
726
727 4.1. Allocation Token Extension Schema
728
729 BEGIN
730 <?xml version="1.0" encoding="UTF-8"?>
731 <schema xmlns="http://www.w3.org/2001/XMLSchema"
732 xmlns:allocationToken="urn:ietf:params:xml:ns:allocationToken-1.0"
733 targetNamespace="urn:ietf:params:xml:ns:allocationToken-1.0"
734 elementFormDefault="qualified">
735 <annotation>
736 <documentation>
737 Extensible Provisioning Protocol v1.0
738 Allocation Token Extension
739 </documentation>
740 </annotation>
741
742 <!-- Element used in info command to get allocation token. -->
743 <element name="info">
744 <complexType>
745 <complexContent>
746 <restriction base="anyType" />
747 </complexContent>
748 </complexType>
749 </element>
750
751 <!-- Allocation Token used in transform
752 commands and info response -->
753 <element name="allocationToken"
754 type="allocationToken:allocationTokenType" />
755 <simpleType name="allocationTokenType">
756 <restriction base="token">
757 <minLength value="1" />
758 </restriction>
759 </simpleType>
760
761 <!-- End of schema. -->
762 </schema>
763 END
764
765
766
767 Gould & Feher Standards Track [Page 14]
768 RFC 8495 Allocation Token November 2018
769
770
771 5. IANA Considerations
772
773 5.1. XML Namespace
774
775 This document uses URNs to describe XML namespaces and XML schemas
776 conforming to a registry mechanism described in [RFC3688].
777
778 The allocationToken namespace has been registered as follows.
779
780 URI: urn:ietf:params:xml:ns:allocationToken-1.0
781 Registrant Contact: IESG
782 XML: None. Namespace URIs do not represent an XML specification.
783
784 The allocationToken XML schema has been registered as follows.
785
786 URI: urn:ietf:params:xml:schema:allocationToken-1.0
787 Registrant Contact: IESG
788 XML: See the "Formal Syntax" section of this document.
789
790 5.2. EPP Extension Registry
791
792 The following entry has been added to the Extensions for the
793 Extensible Provisioning Protocol (EPP) registry, as described in
794 [RFC7451].
795
796 Name of Extension: Allocation Token Extension for the Extensible
797 Provisioning Protocol (EPP)
798
799 Document Status: Standards Track
800
801 Reference: RFC 8495
802
803 Registrant: IESG <iesg@ietf.org>
804
805 TLDs: Any
806
807 IPR Disclosure: None
808
809 Status: Active
810
811 Notes: None
812
813 6. Security Considerations
814
815 The mapping described in this document does not provide any security
816 services beyond those described by EPP [RFC5730] and protocol layers
817 used by EPP. The security considerations described in these other
818 specifications apply to this specification as well.
819
820
821
822 Gould & Feher Standards Track [Page 15]
823 RFC 8495 Allocation Token November 2018
824
825
826 The mapping acts as a conduit for the passing of Allocation Tokens
827 between a client and a server. The definition of the Allocation
828 Token SHOULD be defined outside of this mapping. The following are
829 security considerations in the definition and use of an Allocation
830 Token:
831
832 1. An Allocation Token should be considered secret information by
833 the client; it SHOULD be protected at rest and MUST be protected
834 in transit.
835 2. An Allocation Token should be single use, meaning it should be
836 unique per object and per allocation operation.
837 3. An Allocation Token should have a limited life with some form of
838 expiry in the Allocation Token, if generated by a trusted third
839 party, or with a server-side expiry, if generated by the server.
840 4. An Allocation Token should use a strong random value if it is
841 based on an unsigned code.
842 5. An Allocation Token should leverage digital signatures to confirm
843 its authenticity if generated by a trusted third party.
844 6. An Allocation Token that is signed XML should be encoded (e.g.,
845 base64 [RFC4648]) to mitigate server validation issues.
846
847 7. References
848
849 7.1. Normative References
850
851 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
852 Requirement Levels", BCP 14, RFC 2119,
853 DOI 10.17487/RFC2119, March 1997,
854 <https://www.rfc-editor.org/info/rfc2119>.
855
856 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
857 DOI 10.17487/RFC3688, January 2004,
858 <https://www.rfc-editor.org/info/rfc3688>.
859
860 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
861 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
862 <https://www.rfc-editor.org/info/rfc5730>.
863
864 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
865 Domain Name Mapping", STD 69, RFC 5731,
866 DOI 10.17487/RFC5731, August 2009,
867 <https://www.rfc-editor.org/info/rfc5731>.
868
869 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
870 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
871 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
872
873
874
875
876
877 Gould & Feher Standards Track [Page 16]
878 RFC 8495 Allocation Token November 2018
879
880
881 7.2. Informative References
882
883 [RFC4648] Josefsson, S., "The Base16, Base32, and Base64 Data
884 Encodings", RFC 4648, DOI 10.17487/RFC4648, October 2006,
885 <https://www.rfc-editor.org/info/rfc4648>.
886
887 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
888 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
889 February 2015, <https://www.rfc-editor.org/info/rfc7451>.
890
891 Acknowledgements
892
893 The authors wish to acknowledge the original concept for this
894 document and the efforts in the initial draft versions of this
895 document by Trung Tran and Sharon Wodjenski.
896
897 Special suggestions that have been incorporated into this document
898 were provided by Ben Campbell, Scott Hollenbeck, Benjamin Kaduk,
899 Mirja Kuehlewind, Rubens Kuhl, Alexander Mayrhofer, Patrick Mevzek,
900 Eric Rescoria, and Adam Roach.
901
902 Authors' Addresses
903
904 James Gould
905 VeriSign, Inc.
906 12061 Bluemont Way
907 Reston, VA 20190
908 United States of America
909
910 Email: jgould@verisign.com
911 URI: http://www.verisign.com
912
913
914 Kal Feher
915 Neustar
916 lvl 8/10 Queens Road
917 Melbourne, VIC 3004
918 Australia
919
920 Email: ietf@feherfamily.org
921 URI: http://www.neustar.biz
922
923
924
925
926
927
928
929
930
931
932 Gould & Feher Standards Track [Page 17]
933
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.