1 Internet Engineering Task Force (IETF) J. Gould
2 Request for Comments: 9154 R. Wilhelm
3 Category: Standards Track Verisign, Inc.
4 ISSN: 2070-1721 December 2021
5
6
7 Extensible Provisioning Protocol (EPP) Secure Authorization Information
8 for Transfer
9
10 Abstract
11
12 The Extensible Provisioning Protocol (EPP) (RFC 5730) defines the use
13 of authorization information to authorize a transfer of an EPP
14 object, such as a domain name, between clients that are referred to
15 as "registrars". Object-specific, password-based authorization
16 information (see RFCs 5731 and 5733) is commonly used but raises
17 issues related to the security, complexity, storage, and lifetime of
18 authentication information. This document defines an operational
19 practice, using the EPP RFCs, that leverages the use of strong random
20 authorization information values that are short lived, not stored by
21 the client, and stored by the server using a cryptographic hash that
22 provides for secure authorization information that can safely be used
23 for object transfers.
24
25 Status of This Memo
26
27 This is an Internet Standards Track document.
28
29 This document is a product of the Internet Engineering Task Force
30 (IETF). It represents the consensus of the IETF community. It has
31 received public review and has been approved for publication by the
32 Internet Engineering Steering Group (IESG). Further information on
33 Internet Standards is available in Section 2 of RFC 7841.
34
35 Information about the current status of this document, any errata,
36 and how to provide feedback on it may be obtained at
37 https://www.rfc-editor.org/info/rfc9154.
38
39 Copyright Notice
40
41 Copyright (c) 2021 IETF Trust and the persons identified as the
42 document authors. All rights reserved.
43
44 This document is subject to BCP 78 and the IETF Trust's Legal
45 Provisions Relating to IETF Documents
46 (https://trustee.ietf.org/license-info) in effect on the date of
47 publication of this document. Please review these documents
48 carefully, as they describe your rights and restrictions with respect
49 to this document. Code Components extracted from this document must
50 include Revised BSD License text as described in Section 4.e of the
51 Trust Legal Provisions and are provided without warranty as described
52 in the Revised BSD License.
53
54 Table of Contents
55
56 1. Introduction
57 1.1. Conventions Used in This Document
58 2. Registrant, Registrar, Registry
59 3. Signaling Client and Server Support
60 4. Secure Authorization Information
61 4.1. Secure Random Authorization Information
62 4.2. Authorization Information Time To Live (TTL)
63 4.3. Authorization Information Storage and Transport
64 4.4. Authorization Information Matching
65 5. Create, Transfer, and Secure Authorization Information
66 5.1. <Create> Command
67 5.2. <Update> Command
68 5.3. <Info> Command and Response
69 5.4. <Transfer> Request Command
70 6. Transition Considerations
71 6.1. Transition Phase 1 - Features
72 6.2. Transition Phase 2 - Storage
73 6.3. Transition Phase 3 - Enforcement
74 7. IANA Considerations
75 7.1. XML Namespace
76 7.2. EPP Extension Registry
77 8. Security Considerations
78 9. References
79 9.1. Normative References
80 9.2. Informative References
81 Acknowledgements
82 Authors' Addresses
83
84 1. Introduction
85
86 The Extensible Provisioning Protocol (EPP) [RFC5730] defines the use
87 of authorization information to authorize a transfer of an EPP
88 object, such as a domain name, between clients that are referred to
89 as "registrars". The authorization information is object specific
90 and has been defined in "Extensible Provisioning Protocol (EPP)
91 Domain Name Mapping" [RFC5731] and "Extensible Provisioning Protocol
92 (EPP) Contact Mapping" [RFC5733] as password-based authorization
93 information. Other authorization mechanisms can be used, but in
94 practice the password-based authorization information has been used
95 at the time of object creation, managed with the object update, and
96 used to authorize an object transfer request. What has not been
97 considered is the security of the authorization information, which
98 includes the complexity of the authorization information, the Time To
99 Live (TTL) of the authorization information, and where and how the
100 authorization information is stored.
101
102 The current/original lifecycle for authorization information involves
103 long-term storage of encrypted (not hashed) passwords, which presents
104 a significant latent risk of password compromise and is not
105 consistent with current best practices. The mechanisms in this
106 document provide a way to avoid long-term password storage entirely
107 and to only require the storage of hashed (not retrievable) passwords
108 instead of encrypted passwords.
109
110 This document defines an operational practice, using the EPP RFCs,
111 that leverages the use of strong, random authorization information
112 values that are short lived, not stored by the client, and stored by
113 the server using a cryptographic hash to provide secure authorization
114 information used for transfers. This operational practice can be
115 used to support transfers of any EPP object, where the domain name
116 object as defined in [RFC5731] is used in this document for
117 illustration purposes. Elements of the practice may be used to
118 support the secure use of the authorization information for purposes
119 other than transfer, but any other purposes and the applicable
120 elements are out of scope for this document.
121
122 The overall goal is to have strong, random authorization information
123 values that are short lived and are either not stored or stored as
124 cryptographic hash values by the non-responsible parties. In a
125 registrant, registrar, and registry model, the registrant registers
126 the object through the registrar to the registry. The registrant is
127 the responsible party, and the registrar and the registry are the
128 non-responsible parties. EPP is a protocol between the registrar and
129 the registry, where the registrar is referred to as the "client" and
130 the registry is referred to as the "server". The following are the
131 elements of the operational practice and how the existing features of
132 the EPP RFCs can be leveraged to satisfy them:
133
134 Strong Random Authorization Information: The EPP RFCs define the
135 password-based authorization information value using an XML
136 schema "normalizedString" type, so they don't restrict what can
137 be used in any substantial way. This operational practice
138 defines the recommended mechanism for creating a strong random
139 authorization value that would be generated by the client.
140
141 Short-Lived Authorization Information: The EPP RFCs don't explicitly
142 support short-lived authorization information or a TTL for
143 authorization information, but there are EPP RFC features that
144 can be leveraged to support short-lived authorization
145 information. All of these features are compatible with the EPP
146 RFCs, though not mandatory to implement. As stated in
147 Section 2.6 of [RFC5731], authorization information is assigned
148 when a domain object is created, which results in long-lived
149 authorization information. This specification changes the nature
150 of the authorization information from long lived to short lived.
151 If authorization information is set only when a transfer is in
152 process, the server needs to support an empty authorization
153 information value on create, support setting and unsetting
154 authorization information, and support automatically unsetting
155 the authorization information upon a successful transfer. All of
156 these features can be supported by the EPP RFCs.
157
158 Storing Authorization Information Securely: The EPP RFCs don't
159 specify where and how the authorization information is stored in
160 the client or the server, so there are no restrictions on
161 defining an operational practice for storing the authorization
162 information securely. The operational practice will require the
163 client to not store the authorization information and will
164 require the server to store the authorization information using a
165 cryptographic hash with at least a 256-bit hash function, such as
166 SHA-256 [FIPS-180-4], and with a per-authorization information
167 random salt with at least 128 bits. Returning the authorization
168 information set in an EPP info response will not be supported.
169
170 1.1. Conventions Used in This Document
171
172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
174 "OPTIONAL" in this document are to be interpreted as described in
175 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
176 capitals, as shown here.
177
178 XML [W3C.REC-xml-20081126] is case sensitive. Unless stated
179 otherwise, XML specifications and examples provided in this document
180 MUST be interpreted in the character case presented in order to
181 develop a conforming implementation.
182
183 In examples, "C:" represents lines sent by a protocol client and "S:"
184 represents lines returned by a protocol server. Indentation and
185 empty space in examples are provided only to illustrate element
186 relationships and are not a required feature of this protocol.
187
188 The examples reference XML namespace prefixes that are used for the
189 associated XML namespaces. Implementations MUST NOT depend on the
190 example XML namespaces and instead employ a proper namespace-aware
191 XML parser and serializer to interpret and output the XML documents.
192 The example namespace prefixes used and their associated XML
193 namespaces include the following:
194
195 domain: urn:ietf:params:xml:ns:domain-1.0
196
197 contact: urn:ietf:params:xml:ns:contact-1.0
198
199 2. Registrant, Registrar, Registry
200
201 The EPP RFCs refer to "client" and "server", but when it comes to
202 transfers, there are three types of actors that are involved. This
203 document will refer to these actors as "registrant", "registrar", and
204 "registry". [RFC8499] defines these terms formally for the Domain
205 Name System (DNS). The terms are further described below to cover
206 their roles as actors using the authorization information in the
207 transfer process of any object in the registry, such as a domain name
208 or a contact:
209
210 Registrant: [RFC8499] defines the registrant as "an individual or
211 organization on whose behalf a name in a zone is registered by
212 the registry." The registrant can be the owner of any object in
213 the registry, such as a domain name or a contact. The registrant
214 interfaces with the registrar for provisioning the objects. A
215 transfer is coordinated by the registrant to transfer the
216 sponsorship of the object from one registrar to another. The
217 authorization information is meant to authenticate the registrant
218 as the owner of the object to the non-sponsoring registrar and to
219 authorize the transfer.
220
221 Registrar: [RFC8499] defines the registrar as "a service provider
222 that acts as a go-between for registrants and registries." The
223 registrar interfaces with the registrant for the provisioning of
224 objects, such as domain names and contacts, and with the
225 registries to satisfy the registrant's provisioning requests. A
226 registrar may (1) directly interface with the registrant or
227 (2) indirectly interface with the registrant, typically through
228 one or more resellers. Implementing a transfer using secure
229 authorization information extends through the registrar's
230 reseller channel up to the direct interface with the registrant.
231 The registrar's interface with the registries uses EPP. The
232 registrar's interface with its reseller channel or the registrant
233 is registrar specific. In the EPP RFCs, the registrar is
234 referred to as the "client", since EPP is the protocol used
235 between the registrar and the registry. The sponsoring registrar
236 is the authorized registrar to manage objects on behalf of the
237 registrant. A non-sponsoring registrar is not authorized to
238 manage objects on behalf of the registrant. A transfer of an
239 object's sponsorship is from one registrar, referred to as the
240 "losing registrar", to another registrar, referred to as the
241 "gaining registrar".
242
243 Registry: [RFC8499] defines the registry as "the administrative
244 operation of a zone that allows registration of names within that
245 zone." The registry typically interfaces with the registrars
246 over EPP and generally does not interact directly with the
247 registrant. In the EPP RFCs, the registry is referred to as the
248 "server", since EPP is the protocol used between the registrar
249 and the registry. The registry has a record of the sponsoring
250 registrar for each object and provides the mechanism (over EPP)
251 to coordinate a transfer of an object's sponsorship between
252 registrars.
253
254 3. Signaling Client and Server Support
255
256 This document does not define a new protocol; rather, it defines an
257 operational practice using existing EPP features, where the client
258 and the server can signal support for the operational practice using
259 a namespace URI in the login and greeting extension services. The
260 namespace URI "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-
261 1.0" is used to signal support for the operational practice. The
262 client includes the namespace URI in an <svcExtension> <extURI>
263 element of the <login> command [RFC5730]. The server includes the
264 namespace URI in an <svcExtension> <extURI> element of the greeting
265 [RFC5730].
266
267 A client that receives the namespace URI in the server's greeting
268 extension services can expect the following supported behavior by the
269 server:
270
271 1. Support for an empty authorization information value with a
272 <create> command.
273
274 2. Support for unsetting authorization information with an <update>
275 command.
276
277 3. Support for validating authorization information with an <info>
278 command.
279
280 4. Support for not returning an indication of whether the
281 authorization information is set or unset to the non-sponsoring
282 registrar.
283
284 5. Support for returning an empty authorization information value to
285 the sponsoring registrar when the authorization information is
286 set in an info response.
287
288 6. Support for allowing the passing of a matching non-empty
289 authorization information value to authorize a transfer.
290
291 7. Support for automatically unsetting the authorization information
292 upon successful completion of a transfer.
293
294 A server that receives the namespace URI in the client's <login>
295 command extension services can expect the following supported
296 behavior by the client:
297
298 1. Support for the generation of authorization information using a
299 secure random value.
300
301 2. Support for only setting the authorization information when a
302 transfer is in process.
303
304 4. Secure Authorization Information
305
306 The EPP RFCs ([RFC5731] and [RFC5733]) use password-based
307 authorization information to support transfer with the <domain:pw>
308 element [RFC5731] and with the <contact:pw> element [RFC5733]. Other
309 EPP objects that support password-based authorization information for
310 transfer can use secure authorization information as defined in this
311 document. For authorization information to be secure, it must be
312 generated using a strong random value and have a short TTL. The
313 security of the authorization information is defined in the following
314 sections.
315
316 4.1. Secure Random Authorization Information
317
318 For authorization information to be secure, it MUST be generated
319 using a secure random value. The authorization information is
320 treated as a password, and the required length L of a password,
321 rounded up to the largest whole number, is based on the size N of the
322 set of characters and the desired entropy H, in the equation L =
323 ROUNDUP(H / log_2 N). Given a target entropy, the required length
324 can be calculated after deciding on the set of characters that will
325 be randomized. In accordance with current best practices and noting
326 that the authorization information is a machine-generated value, the
327 implementation SHOULD use at least 128 bits of entropy as the value
328 of H. The lengths below are calculated using that value.
329
330 Calculation of the required length with 128 bits of entropy and with
331 the set of all printable ASCII characters except space (0x20), which
332 consists of the 94 characters 0x21-0x7E:
333
334 ROUNDUP(128 / log_2 94) =~ ROUNDUP(128 / 6.55) =~ ROUNDUP(19.54) = 20
335
336 Calculation of the required length with 128 bits of entropy and with
337 the set of case-insensitive alphanumeric characters, which consists
338 of 36 characters (a-z A-Z 0-9):
339
340 ROUNDUP(128 / log_2 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25
341
342 The strength of the random authorization information is dependent on
343 the random number generator. Suitably strong random number
344 generators are available in a wide variety of implementation
345 environments, including the interfaces listed in Sections 7.1.2 and
346 7.1.3 of [RFC4086]. In environments that do not provide interfaces
347 to strong random number generators, the practices defined in
348 [RFC4086] and Section 4.7.1 of the NIST Federal Information
349 Processing Standards (FIPS) Publication 140-2 [FIPS-140-2] can be
350 followed to produce random values that will be resistant to attack.
351 (Note: FIPS 140-2 has been superseded by FIPS 140-3, but FIPS 140-3
352 does not contain information regarding random number generators.)
353
354 4.2. Authorization Information Time To Live (TTL)
355
356 The authorization information SHOULD only be set when a transfer is
357 in process. This implies that the authorization information has a
358 TTL by which the authorization information is cleared when the TTL
359 expires. The EPP RFCs do not provide definitions for TTL, but since
360 the server supports the setting and unsetting of the authorization
361 information by the sponsoring registrar, the sponsoring registrar can
362 apply a TTL based on client policy. The TTL client policy may be
363 based on proprietary registrar-specific criteria, which provides for
364 a transfer-specific TTL tuned for the particular circumstances of the
365 transaction. The sponsoring registrar will be aware of the TTL, and
366 the sponsoring registrar MUST inform the registrant of the TTL when
367 the authorization information is provided to the registrant.
368
369 4.3. Authorization Information Storage and Transport
370
371 To protect the disclosure of the authorization information, the
372 following requirements apply:
373
374 1. The authorization information MUST be stored by the registry
375 using a strong one-way cryptographic hash with at least a 256-bit
376 hash function, such as SHA-256 [FIPS-180-4], and with a per-
377 authorization information random salt with at least 128 bits.
378
379 2. An empty authorization information value MUST be stored as an
380 undefined value that is referred to as a "NULL" value. The
381 representation of a NULL (undefined) value is dependent on the
382 type of database used.
383
384 3. The authorization information MUST NOT be stored by the losing
385 registrar.
386
387 4. The authorization information MUST only be stored by the gaining
388 registrar as a "transient" value in support of the transfer
389 process.
390
391 5. The plain-text version of the authorization information MUST NOT
392 be written to any logs by a registrar or the registry, nor
393 otherwise recorded where it will persist beyond the transfer
394 process.
395
396 6. All communication that includes the authorization information
397 MUST be over an encrypted channel (for example, see [RFC5734])
398 for EPP.
399
400 7. The registrar's interface for communicating the authorization
401 information with the registrant MUST be over an authenticated and
402 encrypted channel.
403
404 4.4. Authorization Information Matching
405
406 To support the authorization information TTL, as described in
407 Section 4.2, the authorization information must have either a set or
408 unset state. Authorization information that is unset is stored with
409 a NULL (undefined) value. Based on the requirement to store the
410 authorization information using a strong one-way cryptographic hash,
411 as described in Section 4.3, authorization information that is set is
412 stored with a non-NULL hashed value. The empty authorization
413 information value is used as input in both the <create> command
414 (Section 5.1) and the <update> command (Section 5.2) to define the
415 unset state. The matching of the authorization information in the
416 <info> command (Section 5.3) and the <transfer> request command
417 (Section 5.4) is based on the following rules:
418
419 1. Any input authorization information value MUST NOT match an unset
420 authorization information value. For example, in [RFC5731] the
421 input <domain:pw>2fooBAR</domain:pw> must not match an unset
422 authorization information value that used <domain:null/> or
423 <domain:pw/>.
424
425 2. An empty input authorization information value MUST NOT match any
426 set authorization information value.
427
428 3. A non-empty input authorization information value MUST be hashed
429 and matched against the set authorization information value,
430 which is stored using the same hash algorithm.
431
432 5. Create, Transfer, and Secure Authorization Information
433
434 To secure the transfer process using secure authorization information
435 as described in Section 4, the client and server need to implement
436 steps where the authorization information is set only when a transfer
437 is actively in process and ensure that the authorization information
438 is stored securely and transported only over secure channels. The
439 steps for management of the authorization information for transfers
440 include the following:
441
442 1. The registrant requests to register the object with the
443 registrar. The registrar sends the <create> command with an
444 empty authorization information value to the registry, as
445 described in Section 5.1.
446
447 2. The registrant requests from the losing registrar the
448 authorization information to provide to the gaining registrar.
449
450 3. The losing registrar generates a secure random authorization
451 information value and sends it to the registry, as described in
452 Section 5.2, and then provides it to the registrant.
453
454 4. The registrant provides the authorization information value to
455 the gaining registrar.
456
457 5. The gaining registrar optionally verifies the authorization
458 information with the <info> command to the registry, as described
459 in Section 5.3.
460
461 6. The gaining registrar sends the transfer request with the
462 authorization information to the registry, as described in
463 Section 5.4.
464
465 7. If the transfer completes successfully, the registry
466 automatically unsets the authorization information; otherwise,
467 the losing registrar unsets the authorization information when
468 the TTL expires; see Section 5.2.
469
470 The following sections outline the practices of the EPP commands and
471 responses between the registrar and the registry that supports secure
472 authorization information for transfer.
473
474 5.1. <Create> Command
475
476 For a <create> command, the registry MUST allow the passing of an
477 empty authorization information value and MAY disallow the passing of
478 a non-empty authorization information value. By having an empty
479 authorization information value on create, the object is initially
480 not involved in the transfer process. Any EPP object extension that
481 supports setting the authorization information with an
482 "eppcom:pwAuthInfoType" element can pass an empty authorization
483 information value. Examples of such extensions are found in
484 [RFC5731] and [RFC5733].
485
486 Example of passing an empty authorization information value in a
487 domain name <create> command [RFC5731]:
488
489 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
490 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
491 C: <command>
492 C: <create>
493 C: <domain:create
494 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
495 C: <domain:name>example.com</domain:name>
496 C: <domain:authInfo>
497 C: <domain:pw/>
498 C: </domain:authInfo>
499 C: </domain:create>
500 C: </create>
501 C: <clTRID>ABC-12345</clTRID>
502 C: </command>
503 C:</epp>
504
505 Example of passing an empty authorization information value in a
506 contact <create> command [RFC5733]:
507
508 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
509 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
510 C: <command>
511 C: <create>
512 C: <contact:create
513 C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
514 C: <contact:id>sh8013</contact:id>
515 C: <contact:postalInfo type="int">
516 C: <contact:name>John Doe</contact:name>
517 C: <contact:addr>
518 C: <contact:city>Dulles</contact:city>
519 C: <contact:cc>US</contact:cc>
520 C: </contact:addr>
521 C: </contact:postalInfo>
522 C: <contact:email>jdoe@example.com</contact:email>
523 C: <contact:authInfo>
524 C: <contact:pw/>
525 C: </contact:authInfo>
526 C: </contact:create>
527 C: </create>
528 C: <clTRID>ABC-12345</clTRID>
529 C: </command>
530 C:</epp>
531
532 5.2. <Update> Command
533
534 For an <update> command, the registry MUST allow the setting and
535 unsetting of the authorization information. The registrar sets the
536 authorization information by first generating a strong, random
537 authorization information value, based on the information provided in
538 Section 4.1, and setting it in the registry in the <update> command.
539 The importance of generating strong authorization information values
540 cannot be overstated: secure transfers are very important to the
541 Internet to mitigate damage in the form of theft, fraud, and other
542 abuse. It is critical that registrars only use strong, randomly
543 generated authorization information values.
544
545 Because of this, registries may validate the randomness of the
546 authorization information based on the length and character set
547 required by the registry -- for example, validating that an
548 authorization value contains a combination of uppercase, lowercase,
549 and non-alphanumeric characters in an attempt to assess the strength
550 of the value and returning an EPP error result of 2202 ("Invalid
551 authorization information") [RFC5730] if the check fails.
552
553 Such checks are, by their nature, heuristic and imperfect, and may
554 identify well-chosen authorization information values as being not
555 sufficiently strong. Registrars, therefore, must be prepared for an
556 error response of 2202 and respond by generating a new value and
557 trying again, possibly more than once.
558
559 Often, the registrar has the "clientTransferProhibited" status set,
560 so to start the transfer process, the "clientTransferProhibited"
561 status needs to be removed, and the strong, random authorization
562 information value needs to be set. The registrar MUST define a TTL,
563 as described in Section 4.2, and if the TTL expires, the registrar
564 will unset the authorization information.
565
566 Example of removing the "clientTransferProhibited" status and setting
567 the authorization information in a domain name <update> command
568 [RFC5731]:
569
570 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
571 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
572 C: <command>
573 C: <update>
574 C: <domain:update
575 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
576 C: <domain:name>example.com</domain:name>
577 C: <domain:rem>
578 C: <domain:status s="clientTransferProhibited"/>
579 C: </domain:rem>
580 C: <domain:chg>
581 C: <domain:authInfo>
582 C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
583 C: </domain:pw>
584 C: </domain:authInfo>
585 C: </domain:chg>
586 C: </domain:update>
587 C: </update>
588 C: <clTRID>ABC-12345-XYZ</clTRID>
589 C: </command>
590 C:</epp>
591
592 When the registrar-defined TTL expires, the sponsoring registrar MUST
593 cancel the transfer process by unsetting the authorization
594 information value and MAY add back statuses like the
595 "clientTransferProhibited" status. Any EPP object extension that
596 supports setting the authorization information with an
597 "eppcom:pwAuthInfoType" element can pass an empty authorization
598 information value. Examples of such extensions are found in
599 [RFC5731] and [RFC5733]. Setting an empty authorization information
600 value unsets the authorization information. [RFC5731] supports an
601 explicit mechanism of unsetting the authorization information, by
602 passing the <domain:null> authorization information value. The
603 registry MUST support unsetting the authorization information by
604 accepting an empty authorization information value and accepting an
605 explicit unset element if it is supported by the object extension.
606
607 Example of adding the "clientTransferProhibited" status and unsetting
608 the authorization information explicitly in a domain name <update>
609 command [RFC5731]:
610
611 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
612 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
613 C: <command>
614 C: <update>
615 C: <domain:update
616 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
617 C: <domain:name>example.com</domain:name>
618 C: <domain:add>
619 C: <domain:status s="clientTransferProhibited"/>
620 C: </domain:add>
621 C: <domain:chg>
622 C: <domain:authInfo>
623 C: <domain:null/>
624 C: </domain:authInfo>
625 C: </domain:chg>
626 C: </domain:update>
627 C: </update>
628 C: <clTRID>ABC-12345-XYZ</clTRID>
629 C: </command>
630 C:</epp>
631
632 Example of unsetting the authorization information with an empty
633 authorization information value in a domain name <update> command
634 [RFC5731]:
635
636 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
637 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
638 C: <command>
639 C: <update>
640 C: <domain:update
641 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
642 C: <domain:name>example.com</domain:name>
643 C: <domain:add>
644 C: <domain:status s="clientTransferProhibited"/>
645 C: </domain:add>
646 C: <domain:chg>
647 C: <domain:authInfo>
648 C: <domain:pw/>
649 C: </domain:authInfo>
650 C: </domain:chg>
651 C: </domain:update>
652 C: </update>
653 C: <clTRID>ABC-12345-XYZ</clTRID>
654 C: </command>
655 C:</epp>
656
657 Example of unsetting the authorization information with an empty
658 authorization information value in a contact <update> command
659 [RFC5733]:
660
661 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
662 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
663 C: <command>
664 C: <update>
665 C: <contact:update
666 C: xmlns:contact="urn:ietf:params:xml:ns:contact-1.0">
667 C: <contact:id>sh8013</contact:id>
668 C: <contact:chg>
669 C: <contact:authInfo>
670 C: <contact:pw/>
671 C: </contact:authInfo>
672 C: </contact:chg>
673 C: </contact:update>
674 C: </update>
675 C: <clTRID>ABC-12345-XYZ</clTRID>
676 C: </command>
677 C:</epp>
678
679 5.3. <Info> Command and Response
680
681 For an <info> command, the registry MUST allow the passing of a non-
682 empty authorization information value for verification. The gaining
683 registrar can pre-verify the authorization information provided by
684 the registrant prior to submitting the transfer request with the use
685 of the <info> command. The registry compares the hash of the passed
686 authorization information with the hashed authorization information
687 value stored for the object. When the authorization information is
688 not set or the passed authorization information does not match the
689 previously set value, the registry MUST return an EPP error result
690 code of 2202 [RFC5730].
691
692 Example of passing a non-empty authorization information value in a
693 domain name <info> command [RFC5731] to verify the authorization
694 information value:
695
696 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
697 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
698 C: <command>
699 C: <info>
700 C: <domain:info
701 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
702 C: <domain:name>example.com</domain:name>
703 C: <domain:authInfo>
704 C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
705 C: </domain:pw>
706 C: </domain:authInfo>
707 C: </domain:info>
708 C: </info>
709 C: <clTRID>ABC-12345</clTRID>
710 C: </command>
711 C:</epp>
712
713 The info response in object extensions, such as those defined in
714 [RFC5731] and [RFC5733], MUST NOT include the optional authorization
715 information element with a non-empty authorization value. The
716 authorization information is stored as a hash in the registry, so
717 returning the plain-text authorization information is not possible,
718 unless valid plain-text authorization information is passed in the
719 <info> command. The registry MUST NOT return any indication of
720 whether the authorization information is set or unset to the non-
721 sponsoring registrar by not returning the authorization information
722 element in the response. The registry MAY return an indication to
723 the sponsoring registrar that the authorization information is set by
724 using an empty authorization information value. The registry MAY
725 return an indication to the sponsoring registrar that the
726 authorization information is unset by not returning the authorization
727 information element.
728
729 Example of returning an empty authorization information value in a
730 domain name info response [RFC5731] to indicate to the sponsoring
731 registrar that the authorization information is set:
732
733 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
734 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
735 S: <response>
736 S: <result code="1000">
737 S: <msg>Command completed successfully</msg>
738 S: </result>
739 S: <resData>
740 S: <domain:infData
741 S: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
742 S: <domain:name>example.com</domain:name>
743 S: <domain:roid>EXAMPLE1-REP</domain:roid>
744 S: <domain:status s="ok"/>
745 S: <domain:clID>ClientX</domain:clID>
746 S: <domain:authInfo>
747 S: <domain:pw/>
748 S: </domain:authInfo>
749 S: </domain:infData>
750 S: </resData>
751 S: <trID>
752 S: <clTRID>ABC-12345</clTRID>
753 S: <svTRID>54322-XYZ</svTRID>
754 S: </trID>
755 S: </response>
756 S:</epp>
757
758 5.4. <Transfer> Request Command
759
760 For a <transfer> request command, the registry MUST allow the passing
761 of a non-empty authorization information value to authorize a
762 transfer. The registry compares the hash of the passed authorization
763 information with the hashed authorization information value stored
764 for the object. When the authorization information is not set or the
765 passed authorization information does not match the previously set
766 value, the registry MUST return an EPP error result code of 2202
767 [RFC5730]. Whether the transfer occurs immediately or is pending is
768 up to server policy. When the transfer occurs immediately, the
769 registry MUST return the EPP success result code of 1000 ("Command
770 completed successfully") [RFC5730], and when the transfer is pending,
771 the registry MUST return the EPP success result code of 1001
772 ("Command completed successfully; action pending"). The losing
773 registrar MUST be informed of a successful transfer request using an
774 EPP <poll> message.
775
776 Example of passing a non-empty authorization information value in a
777 domain name <transfer> request command [RFC5731] to authorize the
778 transfer:
779
780 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
781 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
782 C: <command>
783 C: <transfer op="request">
784 C: <domain:transfer
785 C: xmlns:domain="urn:ietf:params:xml:ns:domain-1.0">
786 C: <domain:name>example1.com</domain:name>
787 C: <domain:authInfo>
788 C: <domain:pw>LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP
789 C: </domain:pw>
790 C: </domain:authInfo>
791 C: </domain:transfer>
792 C: </transfer>
793 C: <clTRID>ABC-12345</clTRID>
794 C: </command>
795 C:</epp>
796
797 Upon successful completion of the transfer, the registry MUST
798 automatically unset the authorization information. If the transfer
799 request is not submitted within the TTL (Section 4.2) or the transfer
800 is canceled or rejected, the registrar MUST unset the authorization
801 information, as described in Section 5.2.
802
803 6. Transition Considerations
804
805 The goal of the transition considerations is to minimize the impact
806 to the registrars in supporting the Secure Authorization Information
807 Model defined in this document by supporting incremental transition
808 steps. The transition steps are dependent on the starting point of
809 the registry. Registries may have different starting points, since
810 some of the elements of the Secure Authorization Information Model
811 may have already been implemented. The considerations assume a
812 starting point, referred to as the "Classic Authorization Information
813 Model", which incorporates the following steps for management of the
814 authorization information for transfers:
815
816 1. The registrant requests to register the object with the
817 registrar. The registrar sends the <create> command, with a non-
818 empty authorization information value, to the registry. The
819 registry stores the authorization information as an encrypted
820 value and requires a non-empty authorization information value
821 for the life of the object. The registrar may store the long-
822 lived authorization information.
823
824 2. At the time of transfer, the registrant requests from the losing
825 registrar the authorization information to provide to the gaining
826 registrar.
827
828 3. The losing registrar retrieves the locally stored authorization
829 information or queries the registry for authorization information
830 using the <info> command, and provides it to the registrant. If
831 the registry is queried, the authorization information is
832 decrypted and the plain-text authorization information is
833 returned in the info response to the registrar.
834
835 4. The registrant provides the authorization information value to
836 the gaining registrar.
837
838 5. The gaining registrar optionally verifies the authorization
839 information with the <info> command to the registry, by passing
840 the authorization information in the <info> command to the
841 registry.
842
843 6. The gaining registrar sends the transfer request with the
844 authorization information to the registry. The registry will
845 decrypt the stored authorization information to compare to the
846 passed authorization information.
847
848 7. If the transfer completes successfully, the authorization
849 information is not touched by the registry and may be updated by
850 the gaining registrar using the <update> command. If the
851 transfer is canceled or rejected, the losing registrar may reset
852 the authorization information using the <update> command.
853
854 The gaps between the Classic Authorization Information Model and the
855 Secure Authorization Information Model include the following:
856
857 1. Registry requirement for a non-empty authorization information
858 value on create and for the life of the object versus the
859 authorization information not being set on create and only being
860 set when a transfer is in process.
861
862 2. Registry not allowing the authorization information to be unset
863 versus providing support for unsetting the authorization
864 information in the <update> command.
865
866 3. Registry storing the authorization information as an encrypted
867 value versus a hashed value.
868
869 4. Registry support for returning the authorization information
870 versus not returning the authorization information in the info
871 response.
872
873 5. Registry not touching the authorization information versus the
874 registry automatically unsetting the authorization information
875 upon a successful transfer.
876
877 6. Registry possibly validating a shorter authorization information
878 value using password complexity rules versus validating the
879 randomness of a longer authorization information value that meets
880 the required bits of entropy.
881
882 The transition can be handled in the three phases defined in
883 Sections 6.1, 6.2, and 6.3.
884
885 6.1. Transition Phase 1 - Features
886
887 The goal of "Transition Phase 1 - Features" is to implement the
888 needed features in EPP so that the registrar can optionally implement
889 the Secure Authorization Information Model. The features to
890 implement are broken out by the commands and responses below:
891
892 <Create> Command: Change the <create> command to make the
893 authorization information optional, by allowing both a non-empty
894 value and an empty value. This enables a registrar to optionally
895 create objects without an authorization information value, as
896 described in Section 5.1.
897
898 <Update> Command: Change the <update> command to allow unsetting the
899 authorization information, as described in Section 5.2. This
900 enables the registrar to optionally unset the authorization
901 information when the TTL expires or when the transfer is canceled
902 or rejected.
903
904 Transfer Approve Command and Transfer Auto-Approve: Change the
905 transfer approve command and the transfer auto-approve to
906 automatically unset the authorization information. This sets the
907 default state of the object to not have the authorization
908 information set. The registrar implementing the Secure
909 Authorization Information Model will not set the authorization
910 information for an inbound transfer, and the registrar
911 implementing the Classic Authorization Information Model will set
912 the new authorization information upon a successful transfer.
913
914 Info Response: Change the <info> command to not return the
915 authorization information in the info response, as described in
916 Section 5.3. This sets up the implementation of "Transition Phase
917 2 - Storage" (Section 6.2), since the dependency on returning the
918 authorization information in the info response will be removed.
919 This feature is the only one that is not an optional change to the
920 registrar, and this change could potentially break the client, so
921 it's recommended that the registry provide notice of the change.
922
923 <Info> Command and Transfer Request: Change the <info> command and
924 the transfer request to ensure that a registrar cannot get an
925 indication that the authorization information is set or not set by
926 returning the EPP error result code of 2202 when comparing a
927 passed authorization to a non-matching set authorization
928 information value or an unset value.
929
930 6.2. Transition Phase 2 - Storage
931
932 The goal of "Transition Phase 2 - Storage" is to transition the
933 registry to use hashed authorization information instead of encrypted
934 authorization information. There is no direct impact on the
935 registrars, since the only visible indication that the authorization
936 information has been hashed is that the set authorization information
937 is not returned in the info response, as addressed in "Transition
938 Phase 1 - Features" (Section 6.1). Transitioning the authorization
939 information storage includes the following three steps:
940
941 Hash New Authorization Information Values: Change the <create>
942 command and the <update> command to hash rather than encrypt the
943 authorization information.
944
945 Support Comparison against Encrypted or Hashed Authorization
946 Information: Change the <info> command and the <transfer> request
947 command to be able to compare a passed authorization information
948 value with either a hashed or encrypted authorization information
949 value. This requires that the stored values be self-identifying
950 as being in hashed or encrypted form.
951
952 Hash Existing Encrypted Authorization Information Values: Convert
953 the encrypted authorization information values stored in the
954 registry database to hashed values. This update will not be
955 visible to the registrar. The conversion can be done over a
956 period of time, depending on registry policy.
957
958 6.3. Transition Phase 3 - Enforcement
959
960 The goal of "Transition Phase 3 - Enforcement" is to complete the
961 implementation of the Secure Authorization Information Model, by
962 enforcing the following:
963
964 Disallow Authorization Information on <Create> Command: Change the
965 <create> command to not allow the passing of a non-empty
966 authorization information value. This behavior could potentially
967 break the client, so it's recommended that the registry provide
968 notice of this change.
969
970 Validate the Strong Random Authorization Information: Change the
971 validation of the authorization information in the <update>
972 command to ensure at least 128 bits of entropy.
973
974 7. IANA Considerations
975
976 7.1. XML Namespace
977
978 This document uses URNs to describe XML namespaces conforming to the
979 registry mechanism described in [RFC3688]. IANA has assigned the
980 following URI in the "ns" subregistry within the "IETF XML Registry"
981 for secure authorization information for the transfer namespace:
982
983 URI: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0
984 Registrant Contact: IESG
985 XML: None. Namespace URIs do not represent an XML specification.
986
987 7.2. EPP Extension Registry
988
989 IANA has registered the EPP operational practice described in this
990 document in the "Extensions for the Extensible Provisioning Protocol
991 (EPP)" registry as defined in [RFC7451]. The details of the
992 registration are as follows:
993
994 Name of Extension: "Extensible Provisioning Protocol (EPP) Secure
995 Authorization Information for Transfer"
996 Document status: Standards Track
997 Reference: RFC 9154
998 Registrant Name and Email Address: IESG (iesg@ietf.org)
999 TLDs: Any
1000 IPR Disclosure: None
1001 Status: Active
1002 Notes: None
1003
1004 8. Security Considerations
1005
1006 Section 4.1 defines the use of a secure random value for the
1007 generation of authorization information. The client SHOULD choose a
1008 length and set of characters that result in at least 128 bits of
1009 entropy.
1010
1011 Section 4.2 defines the use of an authorization information TTL. The
1012 registrar SHOULD only set the authorization information during the
1013 transfer process by setting the authorization information at the
1014 start of the transfer process and unsetting the authorization
1015 information at the end of the transfer process. The TTL value is
1016 left up to registrar policy, and the sponsoring registrar MUST inform
1017 the registrant of the TTL when providing the authorization
1018 information to the registrant.
1019
1020 Section 4.3 defines the storage and transport of authorization
1021 information. The losing registrar MUST NOT store the authorization
1022 information and the gaining registrar MUST only store the
1023 authorization information as a "transient" value during the transfer
1024 process, where the authorization information MUST NOT be stored after
1025 the end of the transfer process. The registry MUST store the
1026 authorization information using a one-way cryptographic hash of at
1027 least 256 bits and with a per-authorization information random salt
1028 with at least 128 bits. All communication that includes the
1029 authorization information MUST be over an encrypted channel. The
1030 plain-text authorization information MUST NOT be written to any logs
1031 by the registrar or the registry.
1032
1033 Section 4.4 defines the matching of the authorization information
1034 values. The registry stores an unset authorization information value
1035 as a NULL (undefined) value to ensure that an empty input
1036 authorization information value never matches it. The method used to
1037 define a NULL (undefined) value is database specific.
1038
1039 9. References
1040
1041 9.1. Normative References
1042
1043 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
1044 Requirement Levels", BCP 14, RFC 2119,
1045 DOI 10.17487/RFC2119, March 1997,
1046 <https://www.rfc-editor.org/info/rfc2119>.
1047
1048 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
1049 DOI 10.17487/RFC3688, January 2004,
1050 <https://www.rfc-editor.org/info/rfc3688>.
1051
1052 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker,
1053 "Randomness Requirements for Security", BCP 106, RFC 4086,
1054 DOI 10.17487/RFC4086, June 2005,
1055 <https://www.rfc-editor.org/info/rfc4086>.
1056
1057 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
1058 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
1059 <https://www.rfc-editor.org/info/rfc5730>.
1060
1061 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
1062 Domain Name Mapping", STD 69, RFC 5731,
1063 DOI 10.17487/RFC5731, August 2009,
1064 <https://www.rfc-editor.org/info/rfc5731>.
1065
1066 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
1067 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733,
1068 August 2009, <https://www.rfc-editor.org/info/rfc5733>.
1069
1070 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)
1071 Transport over TCP", STD 69, RFC 5734,
1072 DOI 10.17487/RFC5734, August 2009,
1073 <https://www.rfc-editor.org/info/rfc5734>.
1074
1075 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
1076 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
1077 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
1078
1079 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
1080 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499,
1081 January 2019, <https://www.rfc-editor.org/info/rfc8499>.
1082
1083 [W3C.REC-xml-20081126]
1084 Bray, T., Paoli, J., Sperberg-McQueen, M., Maler, E., and
1085 F. Yergeau, "Extensible Markup Language (XML) 1.0 (Fifth
1086 Edition)", World Wide Web Consortium Recommendation REC-
1087 xml-20081126, November 2008,
1088 <https://www.w3.org/TR/2008/REC-xml-20081126>.
1089
1090 9.2. Informative References
1091
1092 [FIPS-140-2]
1093 National Institute of Standards and Technology, U.S.
1094 Department of Commerce, "NIST Federal Information
1095 Processing Standards (FIPS) Publication 140-2",
1096 DOI 10.6028/NIST.FIPS.140-2, May 2001,
1097 <https://csrc.nist.gov/publications/detail/fips/140/2/
1098 final>.
1099
1100 [FIPS-180-4]
1101 National Institute of Standards and Technology, U.S.
1102 Department of Commerce, "Secure Hash Standard, NIST
1103 Federal Information Processing Standards (FIPS)
1104 Publication 180-4", DOI 10.6028/NIST.FIPS.180-4, August
1105 2015,
1106 <https://csrc.nist.gov/publications/detail/fips/180/4/
1107 final>.
1108
1109 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
1110 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
1111 February 2015, <https://www.rfc-editor.org/info/rfc7451>.
1112
1113 Acknowledgements
1114
1115 The authors wish to thank the following persons for their feedback
1116 and suggestions: Michael Bauland, Martin Casanova, Scott Hollenbeck,
1117 Benjamin Kaduk, Jody Kolker, Barry Leiba, Patrick Mevzek, Matthew
1118 Pozun, Srikanth Veeramachaneni, and Ulrich Wisser.
1119
1120 Authors' Addresses
1121
1122 James Gould
1123 Verisign, Inc.
1124 12061 Bluemont Way
1125 Reston, VA 20190
1126 United States of America
1127
1128 Email: jgould@verisign.com
1129 URI: https://www.verisign.com
1130
1131
1132 Richard Wilhelm
1133 Verisign, Inc.
1134 12061 Bluemont Way
1135 Reston, VA 20190
1136 United States of America
1137
1138 Email: 4rickwilhelm@gmail.com
1139 URI: https://www.verisign.com
1140
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.