idnits 2.17.1
draft-gould-regext-secure-authinfo-transfer-01.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** The document seems to lack an IANA Considerations section. (See Section
2.2 of https://www.ietf.org/id-info/checklist for how to handle the case
when there are no actions for IANA.)
Miscellaneous warnings:
----------------------------------------------------------------------------
== The copyright year in the IETF Trust and authors Copyright Line does not
match the current year
-- The document date (June 26, 2019) is 1765 days in the past. Is this
intentional?
Checking references for intended status: Best Current Practice
----------------------------------------------------------------------------
(See RFCs 3967 and 4897 for information about using normative references
to lower-maturity documents in RFCs)
-- Looks like a reference, but probably isn't: '1' on line 769
** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499)
Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--).
Run idnits with the --verbose option for more detailed information about
the items above.
--------------------------------------------------------------------------------
2 Network Working Group J. Gould
3 Internet-Draft R. Wilhelm
4 Intended status: Best Current Practice VeriSign, Inc.
5 Expires: December 28, 2019 June 26, 2019
7 Extensible Provisioning Protocol (EPP) Secure Authorization Information
8 for Transfer
9 draft-gould-regext-secure-authinfo-transfer-01
11 Abstract
13 The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the
14 use of authorization information to authorize a transfer. The
15 authorization information is object-specific and has been defined in
16 the EPP Domain Name Mapping, in RFC 5731, and the EPP Contact
17 Mapping, in RFC 5733, as password-based authorization information.
18 Other authorization mechanisms can be used, but in practice the
19 password-based authorization information has been used at the time of
20 object create, managed with the object update, and used to authorize
21 an object transfer request. What has not been fully considered is
22 the security of the authorization information that includes the
23 complexity of the authorization information, the time-to-live (TTL)
24 of the authorization information, and where and how the authorization
25 information is stored. This document defines an operational
26 practice, using the EPP RFCs, that leverages the use of strong random
27 authorization information values that are short-lived, that are not
28 stored by the client, and that are stored using a cryptographic hash
29 by the server to provide for secure authorization information used
30 for transfers.
32 Status of This Memo
34 This Internet-Draft is submitted in full conformance with the
35 provisions of BCP 78 and BCP 79.
37 Internet-Drafts are working documents of the Internet Engineering
38 Task Force (IETF). Note that other groups may also distribute
39 working documents as Internet-Drafts. The list of current Internet-
40 Drafts is at http://datatracker.ietf.org/drafts/current/.
42 Internet-Drafts are draft documents valid for a maximum of six months
43 and may be updated, replaced, or obsoleted by other documents at any
44 time. It is inappropriate to use Internet-Drafts as reference
45 material or to cite them other than as "work in progress."
47 This Internet-Draft will expire on December 28, 2019.
49 Copyright Notice
51 Copyright (c) 2019 IETF Trust and the persons identified as the
52 document authors. All rights reserved.
54 This document is subject to BCP 78 and the IETF Trust's Legal
55 Provisions Relating to IETF Documents
56 (http://trustee.ietf.org/license-info) in effect on the date of
57 publication of this document. Please review these documents
58 carefully, as they describe your rights and restrictions with respect
59 to this document. Code Components extracted from this document must
60 include Simplified BSD License text as described in Section 4.e of
61 the Trust Legal Provisions and are provided without warranty as
62 described in the Simplified BSD License.
64 Table of Contents
66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
67 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
68 2. Registrant, Registrar, Registry . . . . . . . . . . . . . . . 4
69 3. Secure Authorization Information . . . . . . . . . . . . . . 5
70 3.1. Secure Random Authorization Information . . . . . . . . . 6
71 3.2. Authorization Information Time-To-Live (TTL) . . . . . . 7
72 3.3. Authorization Information Storage and Transport . . . . . 7
73 4. Create, Transfer, and Secure Authorization Information . . . 7
74 4.1. Create Command . . . . . . . . . . . . . . . . . . . . . 8
75 4.2. Update Command . . . . . . . . . . . . . . . . . . . . . 10
76 4.3. Info Command and Response . . . . . . . . . . . . . . . . 14
77 4.4. Transfer Request Command . . . . . . . . . . . . . . . . 14
78 5. Implementation Status . . . . . . . . . . . . . . . . . . . . 15
79 5.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 16
80 5.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 16
81 6. Security Considerations . . . . . . . . . . . . . . . . . . . 17
82 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17
83 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 17
84 8.1. Normative References . . . . . . . . . . . . . . . . . . 17
85 8.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 18
86 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 18
87 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 18
88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18
90 1. Introduction
92 The Extensible Provisioning Protocol (EPP), in [RFC5730], defines the
93 use of authorization information to authorize a transfer. The
94 authorization information is object-specific and has been defined in
95 the EPP Domain Name Mapping, in [RFC5731], and the EPP Contact
96 Mapping, in [RFC5733], as password-based authorization information.
98 Other authorization mechanisms can be used, but in practice the
99 password-based authorization information has been used at the time of
100 object create, managed with the object update, and used to authorize
101 an object transfer request. What has not been considered is the
102 security of the authorization information that includes the
103 complexity of the authorization information, the time-to-live (TTL)
104 of the authorization information, and where and how the authorization
105 information is stored. This document defines an operational
106 practice, using the EPP RFCs, that leverages the use of strong,
107 random authorization information values that are short-lived, that
108 are not stored by the client, and that are stored by the server using
109 a cryptographic hash to provide, for secure authorization information
110 used for transfers. This operational practice can be used to support
111 transfers of any EPP object, where the domain name object defined in
112 [RFC5731] is used in this document for illustration purposes.
114 The overall goal is to have strong, random authorization information
115 values, that are short-lived, and that are either not stored or
116 stored as a cryptographic hash values by the non-responsible parties.
117 In a registrant, registrar, and registry model, the registrant
118 registers the object through the registrar to the registry. The
119 registrant is the responsible party and the registrar and the
120 registry are the non-responsible parties. EPP is a protocol between
121 the registrar and the registry, where the registrar is referred to as
122 the client and the registry is referred to as the server. The
123 following are the elements of the operational practice and how the
124 existing features of the EPP RFCs can be leveraged to satisfy them:
126 "Strong Random Authorization Information": The EPP RFCs define the
127 password-based authorization information value using an XML
128 schema "normalizedString" type, so they don't restrict what can
129 be used in any way. This operational practice defines the
130 recommended mechanism for creating a strong random authorization
131 value, that would be generated by the client.
132 "Short-Lived Authorization Information": The EPP RFCs don't
133 explicitly support short-lived authorization information or a
134 time-to-live (TTL) for authorization information, but there are
135 EPP RFC features that can be leveraged to support short-lived
136 authorization information. If authorization information is set
137 only when there is a transfer in process, the server needs to
138 support empty authorization information on create, support
139 setting and unsetting authorization information, and support
140 automatically unsetting the authorization information upon a
141 successful transfer. All of these features can be supported by
142 the EPP RFCs.
143 "Storing Authorization Information Securely": The EPP RFCs don't
144 specify where and how the authorization information is stored in
145 the client or the server, so there are no restrictions to define
146 an operational practice for storing the authorization information
147 securely. The operational practice will not require the client
148 to store the authorization information and will require the
149 server to store the authorization information using a
150 cryptographic hash. Returning the authorization information set
151 in an EPP info response will not be supported.
153 1.1. Conventions Used in This Document
155 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
156 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
157 document are to be interpreted as described in RFC 2119 [RFC2119].
159 XML is case sensitive. Unless stated otherwise, XML specifications
160 and examples provided in this document MUST be interpreted in the
161 character case presented in order to develop a conforming
162 implementation.
164 In examples, "C:" represents lines returned by a protocol client.
165 Indentation and white space in examples are provided only to
166 illustrate element relationships and are not a REQUIRED feature of
167 this protocol.
169 The examples reference XML namespace prefixes that are used for the
170 associated XML namespaces. Implementations MUST NOT depend on the
171 example XML namespaces and instead employ a proper namespace-aware
172 XML parser and serializer to interpret and output the XML documents.
173 The example namespace prefixes used and their associated XML
174 namespaces include:
176 "domain": urn:ietf:params:xml:ns:domain-1.0
177 "contact": urn:ietf:params:xml:ns:contact-1.0
179 2. Registrant, Registrar, Registry
181 The EPP RFCs refer to client and server, but when it comes to
182 transfers, there are three actors that are involved. This document
183 will refer to the actors as registrant, registrar, and registry.
184 [RFC8499] defines these terms formally for the Domain Name System
185 (DNS). The terms are further described below to cover their roles as
186 actors of using the authorization information in the transfer process
187 of any object in the registry, such as a domain name or a contact:
189 "registrant": [RFC8499] defines the registrant as "an individual or
190 organization on whose behalf a name in a zone is registered by
191 the registry". The registrant can be the owner of any object in
192 the registry, such as a domain name or a contact. The registrant
193 interfaces with the registrar for provisioning the objects. A
194 transfer is coordinated by the registrant to transfer the
195 sponsorship of the object from one registrar to another. The
196 authorization information is meant to authenticate the registrant
197 as the owner of the object to the non-sponsoring registrar and to
198 authorize the transfer.
199 "registrar": [RFC8499] defines the registrar as "a service provider
200 that acts as a go-between for registrants and registries". The
201 registrar interfaces with the registrant for the provisioning of
202 objects, such as domain names and contacts, and with the
203 registries to satisfy the registrant's provisioning requests. A
204 registrar may directly interface with the registrant or may
205 indirectly interface with the registrant, typically through one
206 or more resellers. Implementing a transfer using secure
207 authorization information extends through the registrar's
208 reseller channel up to the direct interface with the registrant.
209 The registrar's interface with the registries uses EPP. The
210 registrar's interface with its reseller channel or the registrant
211 is registrar-specific. In the EPP RFCs, the registrar is
212 referred to as the "client", since EPP is the protocol used
213 between the registrar and the registry. The sponsoring registrar
214 is the authorized registrar to manage objects on behalf of the
215 registrant. A non-sponsoring registrar is not authorized to
216 manage objects on behalf of the registrant. A transfer of an
217 object's sponsorship is from one registrar, referred to as the
218 losing registrar, to another registrar, referred to as the
219 gaining registrar.
220 "registry": [RFC8499] defines the registry as "the administrative
221 operation of a zone that allows registration of names within the
222 zone". The registry typically interfaces with the registrars
223 over EPP and generally does not interact directly with the
224 registrant. In the EPP RFCs, the registry is referred to as the
225 "server", since EPP is the protocol used between the registrar
226 and the registry. The registry has a record of the sponsoring
227 registrar for each object and provides the mechanism (over EPP)
228 to coordinate a transfer of an object's sponsorship between
229 registrars.
231 3. Secure Authorization Information
233 The authorization information in the EPP RFCs ([RFC5731] and
234 [RFC5733]) that support transfer use password-based authorization
235 information. Other EPP objects that support password-based
236 authorization information for transfer can use the Secure
237 Authorization Information defined in this document. For the
238 authorization information to be secure it must be a strong random
239 value and must have a short time-to-live (TTL). The security of the
240 authorization information is defined in the following sections.
242 3.1. Secure Random Authorization Information
244 For authorization information to be secure, it MUST be generated
245 using a secure random value. The authorization information is
246 treated as a password, where according to [RFC4086] a high-security
247 password must have at least 49 bits of randomness or entropy. The
248 required length L of a password, rounded up to the largest whole
249 number, is based on the set of characters N and the desired entropy
250 H, in the equation L = ROUNDUP(H / log2 N). With a target entropy of
251 49, the required length can be calculated after deciding on the set
252 of characters that will be randomized. The following are a set of
253 possible character sets and the calculation of the required length.
255 Calculation of the required length with 49 bits of entropy and with
256 the set of all printable ASCII characters except space (0x20), which
257 consists of the 94 characters 0x21-0x7E.
259 ROUNDUP(49 / log2 94) = ROUNDUP(49 / 6.55) = ROUNDUP(7.48) = 8
261 Calculation of the required length with 49 bits of entropy and with
262 the set of case-insensitive alphanumeric characters, which consists
263 of 36 characters (a-z A-Z 0-9).
265 ROUNDUP(49 / log2 36) = ROUNDUP(49 / 5.17) = ROUNDUP(9.48) = 10
267 Considering the age of [RFC4086], the evolution of security
268 practices, and that the authorization information is a machine-
269 generated value, the recommendation is to use at least 128 bits of
270 entropy. The lengths are recalculated below using 128 bits of
271 entropy.
273 Calculation of the required length with 128 bits of entropy and with
274 the set of all printable ASCII characters except space (0x20), which
275 consists of the 94 characters 0x21-0x7E.
277 ROUNDUP(128 / log2 94) = ROUNDUP(128 / 6.55) = ROUNDUP(19.54) = 20
279 Calculation of the required length with 128 bits of entropy and with
280 the set of case insensitive alphanumeric characters, which consists
281 of 36 characters (a-z A-Z 0-9).
283 ROUNDUP(128 / log2 36) = ROUNDUP(128 / 5.17) = ROUNDUP(24.76) = 25
285 The strength of the random authorization information is dependent on
286 the actual entropy of the underlying random number generator. For
287 the random number generator, the practices defined in [RFC4086] and
288 section 4.7.1 of the NIST Federal Information Processing Standards
289 (FIPS) Publication 140-2 [1] SHOULD be followed to produce random
290 values that will be resistant to attack. A random number generator
291 (RNG) is preferable over the use of a pseudorandom number generator
292 (PRNG) to reduce the predictability of the authorization information.
293 The more predictable the random number generator is, the lower the
294 true entropy, and the longer the required length for the
295 authorization information.
297 3.2. Authorization Information Time-To-Live (TTL)
299 The authorization information SHOULD only be set when there is a
300 transfer in process. This implies that the authorization information
301 has a Time-To-Live (TTL) by which the authorization information is
302 cleared when the TTL expires. The EPP RFCs have no definition of
303 TTL, but since the server supports the setting and unsetting of the
304 authorization information by the sponsoring registrar, then the
305 sponsoring registrar can apply a TTL based on client policy. The TTL
306 client policy may be based on proprietary registrar-specific criteria
307 which provides for a transfer-specific TTL tuned for the particular
308 circumstances of the transaction. The sponsoring registrar will be
309 aware of the TTL and the sponsoring registrar MUST inform the
310 registrant of the TTL when the authorization information is provided
311 to the registrant.
313 3.3. Authorization Information Storage and Transport
315 To protect the disclosure of the authorization information, the
316 authorization information MUST be stored by the registry using a
317 strong one-way cryptographic hash and MUST NOT be stored by the
318 registrar. The plain text version of the authorization information
319 MUST NOT be written to any logs by the registrar or the registry.
320 All communication that includes the authorization information MUST be
321 over an encrypted channel, such as [RFC5734] for EPP. The
322 registrar's interface for communicating the authorization information
323 with the registrant MUST be over an authenticated and encrypted
324 channel.
326 4. Create, Transfer, and Secure Authorization Information
328 To make the transfer process secure using secure authorization
329 information, as defined in Section 3, the client and server need to
330 implement steps where the authorization information is set only when
331 a transfer is actively in process and ensure that the authorization
332 information is stored securely and transported only over secure
333 channels. The steps in management of the authorization information
334 for transfers include:
336 1. Registrant requests to register the object with the registrar.
337 Registrar sends the create command, with empty authorization
338 information, to the registry, as defined in Section 4.1.
339 2. Registrant requests from the losing registrar the authorization
340 information to provide to the gaining registrar.
341 3. Losing registrar generates a secure random authorization
342 information value, sends it to the registry as defined in
343 Section 4.2, and provides it to the registrant.
344 4. Registrant provides the authorization information value to the
345 gaining registrar.
346 5. Gaining registrar optionally verifies the authorization
347 information with the info command to the registry, as defined in
348 Section 4.3.
349 6. Gaining registrar sends the transfer request with the
350 authorization information to the registry, as defined in
351 Section 4.4.
352 7. If the transfer successfully completes, the registry
353 automatically unsets the authorization information; otherwise the
354 losing registrar unsets the authorization information when the
355 TTL expires, as defined in Section 4.2.
357 The following sections outline the practices of the EPP commands and
358 responses between the registrar and the registry that supports secure
359 authorization information for transfer.
361 4.1. Create Command
363 For a Create Command, the registry MUST allow for the passing of an
364 empty authorization information and MAY disallow for the passing of a
365 non-empty authorization information. By having an empty
366 authorization information on create, the object is initially not in
367 the transfer process. Any EPP object extension that supports setting
368 the authorization information with a "eppcom:pwAuthInfoType" element,
369 can have an empty authorization information passed, such as [RFC5731]
370 and [RFC5733].
372 Example of passing empty authorization information in an [RFC5731]
373 domain name create command.
375 C:
376 C:
377 C:
378 C:
379 C:
381 C: example.com
382 C:
383 C:
384 C:
385 C:
386 C:
387 C: ABC-12345
388 C:
389 C:
390 Example of passing empty authorization information in an [RFC5733]
391 contact create command.
393 C:
394 C:
395 C:
396 C:
397 C:
399 C: sh8013
400 C:
401 C: John Doe
402 C: Example Inc.
403 C:
404 C: 123 Example Dr.
405 C: Suite 100
406 C: Dulles
407 C: VA
408 C: 20166-6503
409 C: US
410 C:
411 C:
412 C: +1.7035555555
413 C: +1.7035555556
414 C: jdoe@example.com
415 C:
416 C:
417 C:
418 C:
419 C:
420 C:
421 C:
422 C:
423 C:
424 C: ABC-12345
425 C:
426 C:
428 4.2. Update Command
430 For an Update Command, the registry MUST allow for the setting and
431 unsetting of the authorization information. The registrar sets the
432 authorization information by first generating a strong, random
433 authorization information value, based on Section 3.1, and setting it
434 in the registry in the update command. The registry SHOULD validate
435 the randomness of the authorization information based on the length
436 and character set required by the registry. For example, a registry
437 that requires 20 random printable ASCII characters except space
438 (0x20), should validate that the authorization information contains
439 at least one upper case alpha character, one lower case alpha
440 character, and one non-alpha numeric character. If the authorization
441 information fails the randomness validation, the registry MUST return
442 an EPP error result code of 2202.
444 Often the registrar has the "clientTransferProhibited" status set, so
445 to start the transfer process, the "clientTransferProhibited" status
446 needs to be removed, and the strong, random authorization information
447 value needs to be set. The registrar MUST define a time-to-live
448 (TTL), as defined in Section 3.2, where if the TTL expires the
449 registrar will unset the authorization information.
451 Example of removing the "clientTransferProhibited" status and setting
452 the authorization information in an [RFC5731] domain name update
453 command.
455 C:
456 C:
457 C:
458 C:
459 C:
461 C: example.com
462 C:
463 C:
464 C:
465 C:
466 C:
467 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
468 C:
469 C:
470 C:
471 C:
472 C:
473 C: ABC-12345-XYZ
474 C:
475 C:
477 When the registrar-defined TTL expires, the sponsoring registrar
478 cancels the transfer process by unsetting the authorization
479 information value and may add back statuses like the
480 "clientTransferProbited" status. Any EPP object extension that
481 supports setting the authorization information with a
482 "eppcom:pwAuthInfoType" element, can have an empty authorization
483 information passed, such as [RFC5731] and [RFC5733]. Setting an
484 empty authorization information unsets the value. [RFC5731] supports
485 an explicit mechanism of unsetting the authorization information, by
486 passing the authorization information value. The
487 registry MUST support unsetting the authorization information by
488 accepting an empty authorization information value and accepting an
489 explicit unset element if it is supported by the object extension.
491 Example of unsetting the authorization information explicitly in an
492 [RFC5731] domain name update command.
494 C:
495 C:
496 C:
497 C:
498 C:
500 C: example.com
501 C:
502 C:
503 C:
504 C:
505 C:
506 C:
507 C:
508 C:
509 C:
510 C:
511 C: ABC-12345-XYZ
512 C:
513 C:
514 Example of unsetting the authorization information with an empty
515 authorization information in an [RFC5731] domain name update command.
517 C:
518 C:
519 C:
520 C:
521 C:
523 C: example.com
524 C:
525 C:
526 C:
527 C:
528 C:
529 C:
530 C:
531 C:
532 C:
533 C:
534 C: ABC-12345-XYZ
535 C:
536 C:
538 Example of unsetting the authorization information with an empty
539 authorization information in an [RFC5733] contact update command.
541 C:
542 C:
543 C:
544 C:
545 C:
547 C: sh8013
548 C:
549 C:
550 C:
551 C:
552 C:
553 C:
554 C:
555 C: ABC-12345-XYZ
556 C:
557 C:
559 4.3. Info Command and Response
561 For an Info Command, the registry MUST allow for the passing of a
562 non-empty authorization information for verification. The gaining
563 registrar can pre-verify the authorization information provided by
564 the registrant prior to submitting the transfer request with the use
565 of the Info Command. The registry compares the hash of the passed
566 authorization information with the hashed authorization information
567 value stored for the object. When the authorization information is
568 not set or the passed authorization information does not match the
569 previously set value, the registry MUST return an EPP error result
570 code of 2202 [RFC5730].
572 Example of passing a non-empty authorization information in an
573 [RFC5731] domain name info command to verify the authorization
574 information value.
576 C:
577 C:
578 C:
579 C:
580 C:
582 C: example.com
583 C:
584 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
585 C:
586 C:
587 C:
588 C:
589 C: ABC-12345
590 C:
591 C:
593 The Info Response in object extensions, such as [RFC5731] and
594 [RFC5733], MUST NOT include the optional authorization information
595 element. The authorization information is stored as a hash in the
596 registry, so returning the plain text authorization information is
597 not possible. The registry MUST NOT return any indication of whether
598 the authorization information is set or unset by not returning the
599 authorization information element in the response.
601 4.4. Transfer Request Command
603 For a Transfer Request Command, the registry MUST allow for the
604 passing of a non-empty authorization information to authorize a
605 transfer. The registry compares the hash of the passed authorization
606 information with the hashed authorization information value stored
607 for the object. When the authorization information is not set or the
608 passed authorization information does not match the previously set
609 value, the registry MUST return an EPP error result code of 2202
610 [RFC5730]. Whether the transfer occurs immediately or is pending is
611 up to server policy. When the transfer occurs immediately, the
612 registry MUST return the EPP success result code of 1000 and when the
613 transfer is pending, the registry MUST return the EPP success result
614 code of 1001. The losing registrar MUST be informed of a successful
615 transfer request using an EPP poll message.
617 Example of passing a non-empty authorization information in an
618 [RFC5731] domain name transfer request command to authorize the
619 transfer.
621 C:
622 C:
623 C:
624 C:
625 C:
627 C: example1.com
628 C:
629 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
630 C:
631 C:
632 C:
633 C:
634 C: ABC-12345
635 C:
636 C:
638 Upon successful completion of the transfer, the registry MUST
639 automatically unset the authorization information. If the transfer
640 does not complete within the time-to-live (TTL) (Section 3.2), the
641 registrar MUST unset the authorization information as defined in
642 Section 4.2.
644 5. Implementation Status
646 Note to RFC Editor: Please remove this section and the reference to
647 RFC 7942 [RFC7942] before publication.
649 This section records the status of known implementations of the
650 protocol defined by this specification at the time of posting of this
651 Internet-Draft, and is based on a proposal described in RFC 7942
652 [RFC7942]. The description of implementations in this section is
653 intended to assist the IETF in its decision processes in progressing
654 drafts to RFCs. Please note that the listing of any individual
655 implementation here does not imply endorsement by the IETF.
656 Furthermore, no effort has been spent to verify the information
657 presented here that was supplied by IETF contributors. This is not
658 intended as, and must not be construed to be, a catalog of available
659 implementations or their features. Readers are advised to note that
660 other implementations may exist.
662 According to RFC 7942 [RFC7942], "this will allow reviewers and
663 working groups to assign due consideration to documents that have the
664 benefit of running code, which may serve as evidence of valuable
665 experimentation and feedback that have made the implemented protocols
666 more mature. It is up to the individual working groups to use this
667 information as they see fit".
669 5.1. Verisign EPP SDK
671 Organization: Verisign Inc.
673 Name: Verisign EPP SDK
675 Description: The Verisign EPP SDK includes both a full client
676 implementation and a full server stub implementation of draft-gould-
677 regext-secure-authinfo-transfer.
679 Level of maturity: Development
681 Coverage: All aspects of the protocol are implemented.
683 Licensing: GNU Lesser General Public License
685 Contact: jgould@verisign.com
687 URL: https://www.verisign.com/en_US/channel-resources/domain-
688 registry-products/epp-sdks
690 5.2. RegistryEngine EPP Service
692 Organization: CentralNic
694 Name: RegistryEngine EPP Service
696 Description: Generic high-volume EPP service for gTLDs, ccTLDs and
697 SLDs
699 Level of maturity: Deployed in CentralNic's production environment as
700 well as two other gTLD registry systems, and two ccTLD registry
701 systems.
703 Coverage: Auhtorization Information is "write only" in that the
704 registrars can set the Auhtorization Information, but not get the
705 Auhtorization Information in the Info Response.
707 Licensing: Proprietary In-House software
709 Contact: epp@centralnic.com
711 URL: https://www.centralnic.com
713 6. Security Considerations
715 TBD
717 7. Acknowledgements
719 The authors wish to thank the following persons for their feedback
720 and suggestions:
722 o Scott Hollenbeck
723 o Matthew Pozun
724 o Srikanth Veeramachaneni
726 8. References
728 8.1. Normative References
730 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
731 Requirement Levels", BCP 14, RFC 2119,
732 DOI 10.17487/RFC2119, March 1997, .
735 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
736 "Randomness Requirements for Security", BCP 106, RFC 4086,
737 DOI 10.17487/RFC4086, June 2005, .
740 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
741 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
742 .
744 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
745 Domain Name Mapping", STD 69, RFC 5731,
746 DOI 10.17487/RFC5731, August 2009, .
749 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
750 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
751 August 2009, .
753 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
754 Transport over TCP", STD 69, RFC 5734,
755 DOI 10.17487/RFC5734, August 2009, .
758 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
759 Code: The Implementation Status Section", BCP 205,
760 RFC 7942, DOI 10.17487/RFC7942, July 2016,
761 .
763 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
764 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
765 January 2019, .
767 8.2. URIs
769 [1] https://csrc.nist.gov/publications/detail/fips/140/2/final
771 Appendix A. Change History
773 A.1. Change from 00 to 01
775 1. Filled in the "Implementation Status" section with the inclusion
776 of the "Verisign EPP SDK" and "RegistryEngine EPP Service"
777 implementations.
778 2. Made small wording corrections based on private feedback.
779 3. Added content to the "Acknowledgements" section.
781 Authors' Addresses
783 James Gould
784 VeriSign, Inc.
785 12061 Bluemont Way
786 Reston, VA 20190
787 US
789 Email: jgould@verisign.com
790 URI: http://www.verisign.com
791 Richard Wilhelm
792 VeriSign, Inc.
793 12061 Bluemont Way
794 Reston, VA 20190
795 US
797 Email: rwilhelm@verisign.com
798 URI: http://www.verisign.com