idnits 2.17.1
draft-ietf-regext-secure-authinfo-transfer-00.txt:
Checking boilerplate required by RFC 5378 and the IETF Trust (see
https://trustee.ietf.org/license-info):
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt:
----------------------------------------------------------------------------
No issues found here.
Checking nits according to https://www.ietf.org/id-info/checklist :
----------------------------------------------------------------------------
** 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 (February 14, 2020) is 1533 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 996
** 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: August 17, 2020 February 14, 2020
7 Extensible Provisioning Protocol (EPP) Secure Authorization Information
8 for Transfer
9 draft-ietf-regext-secure-authinfo-transfer-00
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 https://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 August 17, 2020.
49 Copyright Notice
51 Copyright (c) 2020 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 (https://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 . . . . . . . . . . . . . . . . . . . . . . . . 3
67 1.1. Conventions Used in This Document . . . . . . . . . . . . 4
68 2. Registrant, Registrar, Registry . . . . . . . . . . . . . . . 5
69 3. Secure Authorization Information . . . . . . . . . . . . . . 6
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 3.4. Authorization Information Matching . . . . . . . . . . . 8
74 4. Create, Transfer, and Secure Authorization Information . . . 8
75 4.1. Create Command . . . . . . . . . . . . . . . . . . . . . 9
76 4.2. Update Command . . . . . . . . . . . . . . . . . . . . . 11
77 4.3. Info Command and Response . . . . . . . . . . . . . . . . 14
78 4.4. Transfer Request Command . . . . . . . . . . . . . . . . 15
79 5. Transition Considerations . . . . . . . . . . . . . . . . . . 16
80 5.1. Transition Phase 1 - Features . . . . . . . . . . . . . . 18
81 5.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 18
82 5.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 19
83 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 19
84 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 20
85 6.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 20
86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
87 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 21
88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 21
89 9.1. Normative References . . . . . . . . . . . . . . . . . . 21
90 9.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 22
91 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 22
92 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 22
93 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 22
94 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 22
95 A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 24
96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 24
98 1. Introduction
100 The Extensible Provisioning Protocol (EPP), in [RFC5730], defines the
101 use of authorization information to authorize a transfer. The
102 authorization information is object-specific and has been defined in
103 the EPP Domain Name Mapping, in [RFC5731], and the EPP Contact
104 Mapping, in [RFC5733], as password-based authorization information.
105 Other authorization mechanisms can be used, but in practice the
106 password-based authorization information has been used at the time of
107 object create, managed with the object update, and used to authorize
108 an object transfer request. What has not been considered is the
109 security of the authorization information that includes the
110 complexity of the authorization information, the time-to-live (TTL)
111 of the authorization information, and where and how the authorization
112 information is stored. This document defines an operational
113 practice, using the EPP RFCs, that leverages the use of strong,
114 random authorization information values that are short-lived, that
115 are not stored by the client, and that are stored by the server using
116 a cryptographic hash to provide, for secure authorization information
117 used for transfers. This operational practice can be used to support
118 transfers of any EPP object, where the domain name object defined in
119 [RFC5731] is used in this document for illustration purposes.
120 Elements of the practice may be used to support the secure use of the
121 authorization information for purposes other than transfer, but any
122 other purposes and the applicable elements are out-of-scope for this
123 document.
125 The overall goal is to have strong, random authorization information
126 values, that are short-lived, and that are either not stored or
127 stored as a cryptographic hash values by the non-responsible parties.
128 In a registrant, registrar, and registry model, the registrant
129 registers the object through the registrar to the registry. The
130 registrant is the responsible party and the registrar and the
131 registry are the non-responsible parties. EPP is a protocol between
132 the registrar and the registry, where the registrar is referred to as
133 the client and the registry is referred to as the server. The
134 following are the elements of the operational practice and how the
135 existing features of the EPP RFCs can be leveraged to satisfy them:
137 "Strong Random Authorization Information": The EPP RFCs define the
138 password-based authorization information value using an XML
139 schema "normalizedString" type, so they don't restrict what can
140 be used in any way. This operational practice defines the
141 recommended mechanism for creating a strong random authorization
142 value, that would be generated by the client.
143 "Short-Lived Authorization Information": The EPP RFCs don't
144 explicitly support short-lived authorization information or a
145 time-to-live (TTL) for authorization information, but there are
146 EPP RFC features that can be leveraged to support short-lived
147 authorization information. If authorization information is set
148 only when there is a transfer in process, the server needs to
149 support empty authorization information on create, support
150 setting and unsetting authorization information, and support
151 automatically unsetting the authorization information upon a
152 successful transfer. All of these features can be supported by
153 the EPP RFCs.
154 "Storing Authorization Information Securely": The EPP RFCs don't
155 specify where and how the authorization information is stored in
156 the client or the server, so there are no restrictions to define
157 an operational practice for storing the authorization information
158 securely. The operational practice will not require the client
159 to store the authorization information and will require the
160 server to store the authorization information using a
161 cryptographic hash, with at least a 256-bit hash function, such
162 as SHA-256. Returning the authorization information set in an
163 EPP info response will not be supported.
165 1.1. Conventions Used in This Document
167 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
168 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
169 document are to be interpreted as described in RFC 2119 [RFC2119].
171 XML is case sensitive. Unless stated otherwise, XML specifications
172 and examples provided in this document MUST be interpreted in the
173 character case presented in order to develop a conforming
174 implementation.
176 In examples, "C:" represents lines sent by a protocol client and "S:"
177 represents lines returned by a protocol server. Indentation and
178 white space in examples are provided only to illustrate element
179 relationships and are not a required feature of this protocol.
181 The examples reference XML namespace prefixes that are used for the
182 associated XML namespaces. Implementations MUST NOT depend on the
183 example XML namespaces and instead employ a proper namespace-aware
184 XML parser and serializer to interpret and output the XML documents.
185 The example namespace prefixes used and their associated XML
186 namespaces include:
188 "domain": urn:ietf:params:xml:ns:domain-1.0
189 "contact": urn:ietf:params:xml:ns:contact-1.0
191 2. Registrant, Registrar, Registry
193 The EPP RFCs refer to client and server, but when it comes to
194 transfers, there are three types of actors that are involved. This
195 document will refer to the actors as registrant, registrar, and
196 registry. [RFC8499] defines these terms formally for the Domain Name
197 System (DNS). The terms are further described below to cover their
198 roles as actors of using the authorization information in the
199 transfer process of any object in the registry, such as a domain name
200 or a contact:
202 "registrant": [RFC8499] defines the registrant as "an individual or
203 organization on whose behalf a name in a zone is registered by
204 the registry". The registrant can be the owner of any object in
205 the registry, such as a domain name or a contact. The registrant
206 interfaces with the registrar for provisioning the objects. A
207 transfer is coordinated by the registrant to transfer the
208 sponsorship of the object from one registrar to another. The
209 authorization information is meant to authenticate the registrant
210 as the owner of the object to the non-sponsoring registrar and to
211 authorize the transfer.
212 "registrar": [RFC8499] defines the registrar as "a service provider
213 that acts as a go-between for registrants and registries". The
214 registrar interfaces with the registrant for the provisioning of
215 objects, such as domain names and contacts, and with the
216 registries to satisfy the registrant's provisioning requests. A
217 registrar may directly interface with the registrant or may
218 indirectly interface with the registrant, typically through one
219 or more resellers. Implementing a transfer using secure
220 authorization information extends through the registrar's
221 reseller channel up to the direct interface with the registrant.
222 The registrar's interface with the registries uses EPP. The
223 registrar's interface with its reseller channel or the registrant
224 is registrar-specific. In the EPP RFCs, the registrar is
225 referred to as the "client", since EPP is the protocol used
226 between the registrar and the registry. The sponsoring registrar
227 is the authorized registrar to manage objects on behalf of the
228 registrant. A non-sponsoring registrar is not authorized to
229 manage objects on behalf of the registrant. A transfer of an
230 object's sponsorship is from one registrar, referred to as the
231 losing registrar, to another registrar, referred to as the
232 gaining registrar.
233 "registry": [RFC8499] defines the registry as "the administrative
234 operation of a zone that allows registration of names within the
235 zone". The registry typically interfaces with the registrars
236 over EPP and generally does not interact directly with the
237 registrant. In the EPP RFCs, the registry is referred to as the
238 "server", since EPP is the protocol used between the registrar
239 and the registry. The registry has a record of the sponsoring
240 registrar for each object and provides the mechanism (over EPP)
241 to coordinate a transfer of an object's sponsorship between
242 registrars.
244 3. Secure Authorization Information
246 The authorization information in the EPP RFCs ([RFC5731] and
247 [RFC5733]) that support transfer use password-based authorization
248 information. Other EPP objects that support password-based
249 authorization information for transfer can use the Secure
250 Authorization Information defined in this document. For the
251 authorization information to be secure it must be a strong random
252 value and must have a short time-to-live (TTL). The security of the
253 authorization information is defined in the following sections.
255 3.1. Secure Random Authorization Information
257 For authorization information to be secure, it MUST be generated
258 using a secure random value. The authorization information is
259 treated as a password, where according to [RFC4086] a high-security
260 password must have at least 49 bits of randomness or entropy. The
261 required length L of a password, rounded up to the largest whole
262 number, is based on the set of characters N and the desired entropy
263 H, in the equation L = ROUNDUP(H / log2 N). With a target entropy of
264 49, the required length can be calculated after deciding on the set
265 of characters that will be randomized. The following are a set of
266 possible character sets and the calculation of the required length.
268 Calculation of the required length with 49 bits of entropy and with
269 the set of all printable ASCII characters except space (0x20), which
270 consists of the 94 characters 0x21-0x7E.
272 ROUNDUP(49 / log2 94) =~ ROUNDUP(49 / 6.55) =~ ROUNDUP(7.48) = 8
274 Calculation of the required length with 49 bits of entropy and with
275 the set of case-insensitive alphanumeric characters, which consists
276 of 36 characters (a-z A-Z 0-9).
278 ROUNDUP(49 / log2 36) =~ ROUNDUP(49 / 5.17) =~ ROUNDUP(9.48) = 10
280 Considering the age of [RFC4086], the evolution of security
281 practices, and that the authorization information is a machine-
282 generated value, the recommendation is to use at least 128 bits of
283 entropy. The lengths are recalculated below using 128 bits of
284 entropy.
286 Calculation of the required length with 128 bits of entropy and with
287 the set of all printable ASCII characters except space (0x20), which
288 consists of the 94 characters 0x21-0x7E.
290 ROUNDUP(128 / log2 94) =~ ROUNDUP(128 / 6.55) =~ ROUNDUP(19.54) = 20
292 Calculation of the required length with 128 bits of entropy and with
293 the set of case insensitive alphanumeric characters, which consists
294 of 36 characters (a-z A-Z 0-9).
296 ROUNDUP(128 / log2 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25
298 The strength of the random authorization information is dependent on
299 the actual entropy of the underlying random number generator. For
300 the random number generator, the practices defined in [RFC4086] and
301 section 4.7.1 of the NIST Federal Information Processing Standards
302 (FIPS) Publication 140-2 [1] SHOULD be followed to produce random
303 values that will be resistant to attack. A random number generator
304 (RNG) is preferable over the use of a pseudorandom number generator
305 (PRNG) to reduce the predictability of the authorization information.
306 The more predictable the random number generator is, the lower the
307 true entropy, and the longer the required length for the
308 authorization information.
310 3.2. Authorization Information Time-To-Live (TTL)
312 The authorization information SHOULD only be set when there is a
313 transfer in process. This implies that the authorization information
314 has a Time-To-Live (TTL) by which the authorization information is
315 cleared when the TTL expires. The EPP RFCs have no definition of
316 TTL, but since the server supports the setting and unsetting of the
317 authorization information by the sponsoring registrar, then the
318 sponsoring registrar can apply a TTL based on client policy. The TTL
319 client policy may be based on proprietary registrar-specific criteria
320 which provides for a transfer-specific TTL tuned for the particular
321 circumstances of the transaction. The sponsoring registrar will be
322 aware of the TTL and the sponsoring registrar MUST inform the
323 registrant of the TTL when the authorization information is provided
324 to the registrant.
326 3.3. Authorization Information Storage and Transport
328 To protect the disclosure of the authorization information, the
329 following requirements apply:
331 1. The authorization information MUST be stored by the registry
332 using a strong one-way cryptographic hash, with at least a
333 256-bit hash function, such as SHA-256.
335 2. An empty authorization information MUST be stored with a NULL
336 (undefined) value.
337 3. The authorization information MUST NOT be stored by the losing
338 registrar.
339 4. The authorization information MUST only be stored by the gaining
340 registrar as a "transient" value in support of the transfer
341 process.
342 5. The plain text version of the authorization information MUST NOT
343 be written to any logs by the registrar or the registry.
344 6. All communication that includes the authorization information
345 MUST be over an encrypted channel, such as defined in [RFC5734]
346 for EPP.
347 7. The registrar's interface for communicating the authorization
348 information with the registrant MUST be over an authenticated and
349 encrypted channel.
351 3.4. Authorization Information Matching
353 To support the authorization information TTL, as defined in
354 Section 3.2, the authorization information must have either a set or
355 unset state. The unset authorization information is stored with a
356 NULL (undefined) value. Based on the requirement to store the
357 authorization information using a strong one-way cryptographic hash,
358 as defined in Section 3.3, a set authorization information is stored
359 with a non-NULL hashed value. The empty authorization information is
360 used as input in both the create command (Section 4.1) and the update
361 command (Section 4.2) to define the unset state. The matching of the
362 authorization information in the info command (Section 4.3) and the
363 transfer request command (Section 4.4) is based on the following
364 rules:
366 1. Any input authorization information value MUST NOT match an unset
367 authorization information value.
368 2. An empty input authorization information value MUST NOT match any
369 authorization information value.
370 3. A non-empty input authorization information value MUST be hashed
371 and matched against the set authorization information value,
372 which is stored using the same hash algorithm.
374 4. Create, Transfer, and Secure Authorization Information
376 To make the transfer process secure using secure authorization
377 information, as defined in Section 3, the client and server need to
378 implement steps where the authorization information is set only when
379 a transfer is actively in process and ensure that the authorization
380 information is stored securely and transported only over secure
381 channels. The steps in management of the authorization information
382 for transfers include:
384 1. Registrant requests to register the object with the registrar.
385 Registrar sends the create command, with empty authorization
386 information, to the registry, as defined in Section 4.1.
387 2. Registrant requests from the losing registrar the authorization
388 information to provide to the gaining registrar.
389 3. Losing registrar generates a secure random authorization
390 information value, sends it to the registry as defined in
391 Section 4.2, and provides it to the registrant.
392 4. Registrant provides the authorization information value to the
393 gaining registrar.
394 5. Gaining registrar optionally verifies the authorization
395 information with the info command to the registry, as defined in
396 Section 4.3.
397 6. Gaining registrar sends the transfer request with the
398 authorization information to the registry, as defined in
399 Section 4.4.
400 7. If the transfer successfully completes, the registry
401 automatically unsets the authorization information; otherwise the
402 losing registrar unsets the authorization information when the
403 TTL expires, as defined in Section 4.2.
405 The following sections outline the practices of the EPP commands and
406 responses between the registrar and the registry that supports secure
407 authorization information for transfer.
409 4.1. Create Command
411 For a create command, the registry MUST allow for the passing of an
412 empty authorization information and MAY disallow for the passing of a
413 non-empty authorization information. By having an empty
414 authorization information on create, the object is initially not in
415 the transfer process. Any EPP object extension that supports setting
416 the authorization information with a "eppcom:pwAuthInfoType" element,
417 can have an empty authorization information passed, such as [RFC5731]
418 and [RFC5733].
420 Example of passing empty authorization information in an [RFC5731]
421 domain name create command.
423 C:
424 C:
425 C:
426 C:
427 C:
429 C: example.com
430 C:
431 C:
432 C:
433 C:
434 C:
435 C: ABC-12345
436 C:
437 C:
439 Example of passing empty authorization information in an [RFC5733]
440 contact create command.
442 C:
443 C:
444 C:
445 C:
446 C:
448 C: sh8013
449 C:
450 C: John Doe
451 C:
452 C: Dulles
453 C: US
454 C:
455 C:
456 C: jdoe@example.com
457 C:
458 C:
459 C:
460 C:
461 C:
462 C: ABC-12345
463 C:
464 C:
466 4.2. Update Command
468 For an update command, the registry MUST allow for the setting and
469 unsetting of the authorization information. The registrar sets the
470 authorization information by first generating a strong, random
471 authorization information value, based on Section 3.1, and setting it
472 in the registry in the update command. The registry SHOULD validate
473 the randomness of the authorization information based on the length
474 and character set required by the registry. For example, a registry
475 that requires 20 random printable ASCII characters except space
476 (0x20), should validate that the authorization information contains
477 at least one upper case alpha character, one lower case alpha
478 character, and one non-alpha numeric character. If the authorization
479 information fails the randomness validation, the registry MUST return
480 an EPP error result code of 2202.
482 Often the registrar has the "clientTransferProhibited" status set, so
483 to start the transfer process, the "clientTransferProhibited" status
484 needs to be removed, and the strong, random authorization information
485 value needs to be set. The registrar MUST define a time-to-live
486 (TTL), as defined in Section 3.2, where if the TTL expires the
487 registrar will unset the authorization information.
489 Example of removing the "clientTransferProhibited" status and setting
490 the authorization information in an [RFC5731] domain name update
491 command.
493 C:
494 C:
495 C:
496 C:
497 C:
499 C: example.com
500 C:
501 C:
502 C:
503 C:
504 C:
505 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
506 C:
507 C:
508 C:
509 C:
510 C:
511 C: ABC-12345-XYZ
512 C:
513 C:
514 When the registrar-defined TTL expires, the sponsoring registrar
515 cancels the transfer process by unsetting the authorization
516 information value and may add back statuses like the
517 "clientTransferProbited" status. Any EPP object extension that
518 supports setting the authorization information with a
519 "eppcom:pwAuthInfoType" element, can have an empty authorization
520 information passed, such as [RFC5731] and [RFC5733]. Setting an
521 empty authorization information unsets the value. [RFC5731] supports
522 an explicit mechanism of unsetting the authorization information, by
523 passing the authorization information value. The
524 registry MUST support unsetting the authorization information by
525 accepting an empty authorization information value and accepting an
526 explicit unset element if it is supported by the object extension.
528 Example of adding the "clientTransferProhibited" status and unsetting
529 the authorization information explicitly in an [RFC5731] domain name
530 update command.
532 C:
533 C:
534 C:
535 C:
536 C:
538 C: example.com
539 C:
540 C:
541 C:
542 C:
543 C:
544 C:
545 C:
546 C:
547 C:
548 C:
549 C: ABC-12345-XYZ
550 C:
551 C:
552 Example of unsetting the authorization information with an empty
553 authorization information in an [RFC5731] domain name update command.
555 C:
556 C:
557 C:
558 C:
559 C:
561 C: example.com
562 C:
563 C:
564 C:
565 C:
566 C:
567 C:
568 C:
569 C:
570 C:
571 C:
572 C: ABC-12345-XYZ
573 C:
574 C:
576 Example of unsetting the authorization information with an empty
577 authorization information in an [RFC5733] contact update command.
579 C:
580 C:
581 C:
582 C:
583 C:
585 C: sh8013
586 C:
587 C:
588 C:
589 C:
590 C:
591 C:
592 C:
593 C: ABC-12345-XYZ
594 C:
595 C:
597 4.3. Info Command and Response
599 For an info command, the registry MUST allow for the passing of a
600 non-empty authorization information for verification. The gaining
601 registrar can pre-verify the authorization information provided by
602 the registrant prior to submitting the transfer request with the use
603 of the info command. The registry compares the hash of the passed
604 authorization information with the hashed authorization information
605 value stored for the object. When the authorization information is
606 not set or the passed authorization information does not match the
607 previously set value, the registry MUST return an EPP error result
608 code of 2202 [RFC5730].
610 Example of passing a non-empty authorization information in an
611 [RFC5731] domain name info command to verify the authorization
612 information value.
614 C:
615 C:
616 C:
617 C:
618 C:
620 C: example.com
621 C:
622 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
623 C:
624 C:
625 C:
626 C:
627 C: ABC-12345
628 C:
629 C:
631 The info response in object extensions, such as [RFC5731] and
632 [RFC5733], MUST NOT include the optional authorization information
633 element with a non-empty authorization value. The authorization
634 information is stored as a hash in the registry, so returning the
635 plain text authorization information is not possible, unless a valid
636 plain text authorization information is passed in the info command.
637 The registry MUST NOT return any indication of whether the
638 authorization information is set or unset to the non-sponsoring
639 registrar by not returning the authorization information element in
640 the response. The registry MAY return an indication to the
641 sponsoring registrar that the authorization information is set by
642 using an empty authorization information value. The registry MAY
643 return an indication to the sponsoring registrar that the
644 authorization information is unset by not returning the authorization
645 information element.
647 Example of returning an empty authorization information in an
648 [RFC5731] domain name info response to indicate to the sponsoring
649 registrar that the authorization information is set.
651 S:
652 S:
653 S:
654 S:
655 S: Command completed successfully
656 S:
657 S:
658 S:
660 S: example.com
661 S: EXAMPLE1-REP
662 S:
663 S: ClientX
664 S:
665 S:
666 S:
667 S:
668 S:
669 S:
670 S: ABC-12345
671 S: 54322-XYZ
672 S:
673 S:
674 S:
676 4.4. Transfer Request Command
678 For a Transfer Request Command, the registry MUST allow for the
679 passing of a non-empty authorization information to authorize a
680 transfer. The registry compares the hash of the passed authorization
681 information with the hashed authorization information value stored
682 for the object. When the authorization information is not set or the
683 passed authorization information does not match the previously set
684 value, the registry MUST return an EPP error result code of 2202
685 [RFC5730]. Whether the transfer occurs immediately or is pending is
686 up to server policy. When the transfer occurs immediately, the
687 registry MUST return the EPP success result code of 1000 and when the
688 transfer is pending, the registry MUST return the EPP success result
689 code of 1001. The losing registrar MUST be informed of a successful
690 transfer request using an EPP poll message.
692 Example of passing a non-empty authorization information in an
693 [RFC5731] domain name transfer request command to authorize the
694 transfer.
696 C:
697 C:
698 C:
699 C:
700 C:
702 C: example1.com
703 C:
704 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
705 C:
706 C:
707 C:
708 C:
709 C: ABC-12345
710 C:
711 C:
713 Upon successful completion of the transfer, the registry MUST
714 automatically unset the authorization information. If the transfer
715 request is not submitted within the time-to-live (TTL) (Section 3.2)
716 or the transfer is cancelled or rejected, the registrar MUST unset
717 the authorization information as defined in Section 4.2.
719 5. Transition Considerations
721 The goal of the transition considerations to the practice defined in
722 this document, referred to as the Secure Authorization Information
723 Model, is to minimize the impact to the registrars by supporting
724 incremental steps of adoption. The transtion steps are dependent on
725 the starting point of the registry. Registries may have different
726 starting points, since some of the elements of the Secure
727 Authorization Information Model may have already been implemented.
728 The considerations assume a starting point, referred to as the
729 Classic Authorization Information Model, that have the following
730 steps in the management of the authorization information for
731 transfers:
733 1. Registrant requests to register the object with the registrar.
734 Registrar sends the create command, with a non-empty
735 authorization information, to the registry. The registry stores
736 the authorization information as an encrypted value and requires
737 a non-empty authorization information for the life of the object.
738 The registrar may store the long-lived authorization information.
740 2. At the time of transfer, Registrant requests from the losing
741 registrar the authorization information to provide to the gaining
742 registrar.
743 3. Losing registrar retrieves the stored authorization information
744 locally or queries the registry for authorization information
745 using the info command, and provides it to the registrant. If
746 the registry is queried, the authorization information is
747 decrypted and the plain text authorization information is
748 returned in the info response to the registrar.
749 4. Registrant provides the authorization information value to the
750 gaining registrar.
751 5. Gaining registrar optionally verifies the authorization
752 information with the info command to the registry, by passing the
753 authorization information in the info command to the registry.
754 6. Gaining registrar sends the transfer request with the
755 authorization information to the registry. The registry will
756 decrypt the stored authorization information to compare to the
757 passed authorization information.
758 7. If the transfer successfully completes, the authorization
759 information is not touched by the registry and may be updated by
760 the gaining registrar using the update command. If the transfer
761 is cancelled or rejected, the losing registrar may reset the
762 authorization information using the update command.
764 The gaps between the Classic Authorization Information Model and the
765 Secure Authorization Information Model include:
767 1. Registry requirement for a non-empty authorization information on
768 create and for the life of the object versus the authorization
769 information not being set on create and only being set when a
770 transfer is in process.
771 2. Registry not allowing the authorization information to be unset
772 versus supporting the authorization to be unset in the update
773 command.
774 3. Registry storing the authorization information as an encrypted
775 value versus as a hashed value.
776 4. Registry support for returning the authorization information
777 versus not returning the authorization information in the info
778 response.
779 5. Registry not touching the authorization information versus the
780 registry automatically unsetting the authorization information
781 upon a successful transfer.
782 6. Registry may validate a shorter authorization information value
783 using password complexity rules versus validating the randomness
784 of a longer authorization information value that meets the
785 required bits of entropy.
787 The transition can be handled in the three phases defined in the sub-
788 sections Section 5.1, Section 5.2, Section 5.3.
790 5.1. Transition Phase 1 - Features
792 The goal of the "Transition Phase 1 - Features" is to implement the
793 needed features in EPP so that the registrar can optionally implement
794 the Secure Authorization Information Model. The features to
795 implement are broken out by the command and responses below:
797 Create Command: Change the create command to make the authorization
798 information optional, by allowing both a non-empty value and an
799 empty value. This enables a registrar to optionally create
800 objects without an authorization information value, as defined in
801 Section 4.1.
802 Update Command: Change the update command to allow unsetting the
803 authorization information, as defined in Section 4.2. This
804 enables the registrar to optionally unset the authorization
805 information when the TTL expires or when the transfer is cancelled
806 or rejected.
807 Transfer Approve Command and Transfer Auto-Approve: Change the
808 transfer approve command and the transfer auto-approve to
809 automatically unset the authorization information. This sets the
810 default state of the object to not have the authorization
811 information set. The registrar implementing the Secure
812 Authorization Information Model will not set the authorization
813 information for an inbound transfer and the registrar implementing
814 the Classic Authorization Information Model will set the new
815 authorization information upon the successful transfer.
816 Info Response: Change the info command to not return the
817 authorization information in the info response, as defined in
818 Section 4.3. This sets up the implementation of "Transition Phase
819 2 - Storage", since the dependency in returning the authorization
820 information in the info response will be removed. This feature is
821 the only one that is not an optional change to the registrar.
822 Info Command and Transfer Request: Change the info command and the
823 transfer request to ensure that a registrar cannot get an
824 indication that the authorization information is set or not set by
825 returning the EPP error result code of 2202 when comparing a
826 passed authorization to a non-matching set authorization
827 information value or an unset value.
829 5.2. Transition Phase 2 - Storage
831 The goal of the "Transition Phase 2 - Storage" is to transition the
832 registry to use hashed authorization information instead of encrypted
833 authorization information. There is no direct impact to the
834 registrars, since the only visible indication that the authorization
835 information has been hashed is by not returning the set authorization
836 information in the info response, which is addressed in Transition
837 Phase 1 - Features (Section 5.1). There are three steps to
838 transition the authorization information storage, which includes:
840 Hash New Authorization Information Values: Change the create command
841 and the update command to hash instead of encyrpting the
842 authorization information.
843 Supporting Comparing Against Encrypted and Hashed Authorization
844 Information:
845 Change the info command and the transfer request command to be
846 able to compare a passed authorization information value with
847 either a hashed or encyrpted authorization information value.
848 Hash Existing Encrypted Authorization Information Values: Convert
849 the encrypted authorization information values stored in the
850 registry database to hashed values. The update is not a visible
851 change to the registrar. The conversion can be done over a period
852 of time depending on registry policy.
854 5.3. Transition Phase 3 - Enforcement
856 The goal of the "Transition Phase 3 - Enforcement" is to complete the
857 implementation of the "Secure Authorization Information Model", by
858 enforcing the following:
860 Disallow Authorization Information on Create Command: Change the
861 create command to not allow for the passing of a non-empty
862 authorization information value.
863 Validate the Strong Random Authorization Information: Change the
864 validation of the authorization information in the update command
865 to ensure at least 128 bits of entropy.
867 6. Implementation Status
869 Note to RFC Editor: Please remove this section and the reference to
870 RFC 7942 [RFC7942] before publication.
872 This section records the status of known implementations of the
873 protocol defined by this specification at the time of posting of this
874 Internet-Draft, and is based on a proposal described in RFC 7942
875 [RFC7942]. The description of implementations in this section is
876 intended to assist the IETF in its decision processes in progressing
877 drafts to RFCs. Please note that the listing of any individual
878 implementation here does not imply endorsement by the IETF.
879 Furthermore, no effort has been spent to verify the information
880 presented here that was supplied by IETF contributors. This is not
881 intended as, and must not be construed to be, a catalog of available
882 implementations or their features. Readers are advised to note that
883 other implementations may exist.
885 According to RFC 7942 [RFC7942], "this will allow reviewers and
886 working groups to assign due consideration to documents that have the
887 benefit of running code, which may serve as evidence of valuable
888 experimentation and feedback that have made the implemented protocols
889 more mature. It is up to the individual working groups to use this
890 information as they see fit".
892 6.1. Verisign EPP SDK
894 Organization: Verisign Inc.
896 Name: Verisign EPP SDK
898 Description: The Verisign EPP SDK includes both a full client
899 implementation and a full server stub implementation of draft-ietf-
900 regext-secure-authinfo-transfer.
902 Level of maturity: Development
904 Coverage: All aspects of the protocol are implemented.
906 Licensing: GNU Lesser General Public License
908 Contact: jgould@verisign.com
910 URL: https://www.verisign.com/en_US/channel-resources/domain-
911 registry-products/epp-sdks
913 6.2. RegistryEngine EPP Service
915 Organization: CentralNic
917 Name: RegistryEngine EPP Service
919 Description: Generic high-volume EPP service for gTLDs, ccTLDs and
920 SLDs
922 Level of maturity: Deployed in CentralNic's production environment as
923 well as two other gTLD registry systems, and two ccTLD registry
924 systems.
926 Coverage: Auhtorization Information is "write only" in that the
927 registrars can set the Auhtorization Information, but not get the
928 Auhtorization Information in the Info Response.
930 Licensing: Proprietary In-House software
932 Contact: epp@centralnic.com
934 URL: https://www.centralnic.com
936 7. Security Considerations
938 TBD
940 8. Acknowledgements
942 The authors wish to thank the following persons for their feedback
943 and suggestions:
945 o Michael Bauland
946 o Martin Casanova
947 o Scott Hollenbeck
948 o Jody Kolker
949 o Patrick Mevzek
950 o Matthew Pozun
951 o Srikanth Veeramachaneni
953 9. References
955 9.1. Normative References
957 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
958 Requirement Levels", BCP 14, RFC 2119,
959 DOI 10.17487/RFC2119, March 1997,
960 .
962 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
963 "Randomness Requirements for Security", BCP 106, RFC 4086,
964 DOI 10.17487/RFC4086, June 2005,
965 .
967 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
968 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
969 .
971 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
972 Domain Name Mapping", STD 69, RFC 5731,
973 DOI 10.17487/RFC5731, August 2009,
974 .
976 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
977 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
978 August 2009, .
980 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
981 Transport over TCP", STD 69, RFC 5734,
982 DOI 10.17487/RFC5734, August 2009,
983 .
985 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
986 Code: The Implementation Status Section", BCP 205,
987 RFC 7942, DOI 10.17487/RFC7942, July 2016,
988 .
990 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
991 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
992 January 2019, .
994 9.2. URIs
996 [1] https://csrc.nist.gov/publications/detail/fips/140/2/final
998 Appendix A. Change History
1000 A.1. Change from 00 to 01
1002 1. Filled in the "Implementation Status" section with the inclusion
1003 of the "Verisign EPP SDK" and "RegistryEngine EPP Service"
1004 implementations.
1005 2. Made small wording corrections based on private feedback.
1006 3. Added content to the "Acknowledgements" section.
1008 A.2. Change from 01 to 02
1010 1. Revised the language used for the storage of the authorization
1011 information based on the feedback from Patrick Mevzek and Jody
1012 Kolker.
1014 A.3. Change from 02 to 03
1016 1. Updates based on the feedback from the interim REGEXT meeting
1017 held at ICANN-66:
1019 1. Section 3.3, include a reference to the hash algorithm to
1020 use. Broke the requirements into a list and included a the
1021 reference the text ', with at least a 256-bit hash function,
1022 such as SHA-256'.
1024 2. Add a Transition Considerations section to cover the
1025 transition from the classic authorization information
1026 security model in the EPP RFCs to the model defined in the
1027 document.
1028 3. Add a statement to the Introduction that elements of the
1029 practice can be used for purposes other than transfer, but
1030 with a caveat.
1031 2. Updates based on the review by Michael Bauland, that include:
1033 1. In section 2, change 'there are three actors' to 'there are
1034 three types of actors' to cover the case with transfers that
1035 has two registrar actors (losing and gaining).
1036 2. In section 3.1, change the equations equals to be
1037 approximately equal by using '=~' instead of '=', where
1038 applicable.
1039 3. In section 3.3, change 'MUST be over an encrypted channel,
1040 such as [RFC5734]'' to 'MUST be over an encrypted channel,
1041 such as defined in [RFC5734]''.
1042 4. In section 4.1, remove the optional RFC 5733 elements from
1043 the contact create, which includes the ,
1044 , , ,
1045 , , and elements.
1046 5. In section 4.2, changed 'Example of unsetting the
1047 authorization information explicitly in an [RFC5731] domain
1048 name update command.' to 'Example of adding the
1049 "clientTransferProhibited" status and unsetting the
1050 authorization information explicitly in an [RFC5731] domain
1051 name update command.'
1052 6. In section 4.3, cover a corner case of the ability to return
1053 the authorization information when it's passed in the info
1054 command.
1055 7. In section 4.4, change 'If the transfer does not complete
1056 within the time-to-live (TTL)' to 'If the transfer is not
1057 initiated within the time-to-live (TTL)', since the TTL is
1058 the time between setting the authorization information and
1059 when it's successfully used in a transfer request. Added the
1060 case of unsetting the authorization information when the
1061 transfer is cancelled or rejected.
1062 3. Updates based on the authorization information messages by Martin
1063 Casanova on the REGEXT mailing list, that include:
1065 1. Added section 3.4 'Authorization Information Matching' to
1066 clarify how the authorization information is matched, when
1067 there is set and unset authorization information in the
1068 database and empty and non-empty authorization information
1069 passed in the info and transfer commands.
1070 2. Added support for signaling that the authorization
1071 information is set or unset to the sponsoring registrar with
1072 the inclusion of an empty authorization information element
1073 in the response to indicate that the authorization
1074 information is set and the exclusion of the authorization
1075 information element in the response to indicate that the
1076 authorization information is unset.
1077 4. Made the capitalization of command and response references
1078 consistent by uppercasing section and item titles and lowercasing
1079 references elsewhere.
1081 A.4. Change from 03 to REGEXT 00
1083 1. Changed to regext working group draft by changing draft-gould-
1084 regext-secure-authinfo-transfer to draft-ietf-regext-secure-
1085 authinfo-transfer.
1087 Authors' Addresses
1089 James Gould
1090 VeriSign, Inc.
1091 12061 Bluemont Way
1092 Reston, VA 20190
1093 US
1095 Email: jgould@verisign.com
1096 URI: http://www.verisign.com
1098 Richard Wilhelm
1099 VeriSign, Inc.
1100 12061 Bluemont Way
1101 Reston, VA 20190
1102 US
1104 Email: rwilhelm@verisign.com
1105 URI: http://www.verisign.com