idnits 2.17.1 draft-ietf-regext-secure-authinfo-transfer-07.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (28 June 2021) is 1026 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gould 3 Internet-Draft R. Wilhelm 4 Intended status: Standards Track VeriSign, Inc. 5 Expires: 30 December 2021 28 June 2021 7 Extensible Provisioning Protocol (EPP) Secure Authorization Information 8 for Transfer 9 draft-ietf-regext-secure-authinfo-transfer-07 11 Abstract 13 The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the 14 use of authorization information to authorize a transfer of an EPP 15 object, such as a domain name, between clients that are referred to 16 as registrars. Object-specific, password-based authorization 17 information (see RFC 5731 and RFC 5733) is commonly used, but raises 18 issues related to the security, complexity, storage, and lifetime of 19 authentication information. This document defines an operational 20 practice, using the EPP RFCs, that leverages the use of strong random 21 authorization information values that are short-lived, not stored by 22 the client, and stored by the server using a cryptographic hash that 23 provides for secure authorization information that can safely be used 24 for object transfers. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at https://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on 30 December 2021. 43 Copyright Notice 45 Copyright (c) 2021 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 50 license-info) in effect on the date of publication of this document. 51 Please review these documents carefully, as they describe your rights 52 and restrictions with respect to this document. Code Components 53 extracted from this document must include Simplified BSD License text 54 as described in Section 4.e of the Trust Legal Provisions and are 55 provided without warranty as described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 61 2. Registrant, Registrar, Registry . . . . . . . . . . . . . . . 5 62 3. Signaling Client and Server Support . . . . . . . . . . . . . 6 63 4. Secure Authorization Information . . . . . . . . . . . . . . 7 64 4.1. Secure Random Authorization Information . . . . . . . . . 7 65 4.2. Authorization Information Time-To-Live (TTL) . . . . . . 8 66 4.3. Authorization Information Storage and Transport . . . . . 8 67 4.4. Authorization Information Matching . . . . . . . . . . . 9 68 5. Create, Transfer, and Secure Authorization Information . . . 10 69 5.1. Create Command . . . . . . . . . . . . . . . . . . . . . 10 70 5.2. Update Command . . . . . . . . . . . . . . . . . . . . . 12 71 5.3. Info Command and Response . . . . . . . . . . . . . . . . 15 72 5.4. Transfer Request Command . . . . . . . . . . . . . . . . 17 73 6. Transition Considerations . . . . . . . . . . . . . . . . . . 18 74 6.1. Transition Phase 1 - Features . . . . . . . . . . . . . . 20 75 6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 21 76 6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 21 77 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 78 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 21 79 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 22 80 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 22 81 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 23 82 8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 23 83 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 85 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 86 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 87 11.2. Informative References . . . . . . . . . . . . . . . . . 25 88 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 26 89 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 26 90 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 26 91 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 26 92 A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 28 93 A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 28 94 A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 28 95 A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 28 96 A.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 28 97 A.9. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 28 98 A.10. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 29 99 A.11. Change from REGEXT 06 to REGEXT 07 . . . . . . . . . . . 29 100 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 31 102 1. Introduction 104 The Extensible Provisioning Protocol (EPP), in [RFC5730], defines the 105 use of authorization information to authorize a transfer of an EPP 106 object, such as a domain name, between clients that are referred to 107 as registrars. The authorization information is object-specific and 108 has been defined in the EPP Domain Name Mapping, in [RFC5731], and 109 the EPP Contact Mapping, in [RFC5733], as password-based 110 authorization information. Other authorization mechanisms can be 111 used, but in practice the password-based authorization information 112 has been used at the time of object create, managed with the object 113 update, and used to authorize an object transfer request. What has 114 not been considered is the security of the authorization information 115 that includes the complexity of the authorization information, the 116 time-to-live (TTL) of the authorization information, and where and 117 how the authorization information is stored. 119 The current/original lifecycle for authorization information involves 120 long-term storage of encrypted (not hashed) passwords, which presents 121 a significant latent risk of password compromise and is not 122 consistent with current best practices. The mechanisms in this 123 document provide a way to avoid long-term password storage entirely, 124 and to only require the storage of hashed (not retrievable) passwords 125 instead of encrypted passwords. 127 This document defines an operational practice, using the EPP RFCs, 128 that leverages the use of strong, random authorization information 129 values that are short-lived, that are not stored by the client, and 130 that are stored by the server using a cryptographic hash to provide 131 secure authorization information used for transfers. This 132 operational practice can be used to support transfers of any EPP 133 object, where the domain name object defined in [RFC5731] is used in 134 this document for illustration purposes. Elements of the practice 135 may be used to support the secure use of the authorization 136 information for purposes other than transfer, but any other purposes 137 and the applicable elements are out-of-scope for this document. 139 The overall goal is to have strong, random authorization information 140 values, that are short-lived, and that are either not stored or 141 stored as a cryptographic hash values by the non-responsible parties. 142 In a registrant, registrar, and registry model, the registrant 143 registers the object through the registrar to the registry. The 144 registrant is the responsible party and the registrar and the 145 registry are the non-responsible parties. EPP is a protocol between 146 the registrar and the registry, where the registrar is referred to as 147 the client and the registry is referred to as the server. The 148 following are the elements of the operational practice and how the 149 existing features of the EPP RFCs can be leveraged to satisfy them: 151 "Strong Random Authorization Information": The EPP RFCs define the 152 password-based authorization information value using an XML 153 schema "normalizedString" type, so they don't restrict what can 154 be used in any substantial way. This operational practice 155 defines the recommended mechanism for creating a strong random 156 authorization value, that would be generated by the client. 157 "Short-Lived Authorization Information": The EPP RFCs don't 158 explicitly support short-lived authorization information or a 159 time-to-live (TTL) for authorization information, but there are 160 EPP RFC features that can be leveraged to support short-lived 161 authorization information. All of these features are compatible 162 with the EPP RFCs, though not mandatory to implement. In section 163 2.6 of [RFC5731] it states that authorization information is 164 assigned when a domain object is created, which results in long- 165 lived authorization information. This specification changes the 166 nature of the authorization information to be short-lived. If 167 authorization information is set only when there is a transfer in 168 process, the server needs to support an empty authorization 169 information value on create, support setting and unsetting 170 authorization information, and support automatically unsetting 171 the authorization information upon a successful transfer. All of 172 these features can be supported by the EPP RFCs. 173 "Storing Authorization Information Securely": The EPP RFCs don't 174 specify where and how the authorization information is stored in 175 the client or the server, so there are no restrictions to define 176 an operational practice for storing the authorization information 177 securely. The operational practice will require the client to 178 not store the authorization information and will require the 179 server to store the authorization information using a 180 cryptographic hash, with at least a 256-bit hash function, such 181 as SHA-256 [FIPS-180-4], and with a per-authorization information 182 random salt, with at least 128 bits. Returning the authorization 183 information set in an EPP info response will not be supported. 185 1.1. Conventions Used in This Document 187 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 188 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 189 "OPTIONAL" in this document are to be interpreted as described in BCP 190 14 [RFC2119] [RFC8174] when, and only when, they appear in all 191 capitals, as shown here. 193 XML is case sensitive. Unless stated otherwise, XML specifications 194 and examples provided in this document MUST be interpreted in the 195 character case presented in order to develop a conforming 196 implementation. 198 In examples, "C:" represents lines sent by a protocol client and "S:" 199 represents lines returned by a protocol server. Indentation and 200 white space in examples are provided only to illustrate element 201 relationships and are not a required feature of this protocol. 203 The examples reference XML namespace prefixes that are used for the 204 associated XML namespaces. Implementations MUST NOT depend on the 205 example XML namespaces and instead employ a proper namespace-aware 206 XML parser and serializer to interpret and output the XML documents. 207 The example namespace prefixes used and their associated XML 208 namespaces include: 210 "domain": urn:ietf:params:xml:ns:domain-1.0 211 "contact": urn:ietf:params:xml:ns:contact-1.0 213 2. Registrant, Registrar, Registry 215 The EPP RFCs refer to client and server, but when it comes to 216 transfers, there are three types of actors that are involved. This 217 document will refer to the actors as registrant, registrar, and 218 registry. [RFC8499] defines these terms formally for the Domain Name 219 System (DNS). The terms are further described below to cover their 220 roles as actors of using the authorization information in the 221 transfer process of any object in the registry, such as a domain name 222 or a contact: 224 "registrant": [RFC8499] defines the registrant as "an individual or 225 organization on whose behalf a name in a zone is registered by 226 the registry". The registrant can be the owner of any object in 227 the registry, such as a domain name or a contact. The registrant 228 interfaces with the registrar for provisioning the objects. A 229 transfer is coordinated by the registrant to transfer the 230 sponsorship of the object from one registrar to another. The 231 authorization information is meant to authenticate the registrant 232 as the owner of the object to the non-sponsoring registrar and to 233 authorize the transfer. 234 "registrar": [RFC8499] defines the registrar as "a service provider 235 that acts as a go-between for registrants and registries". The 236 registrar interfaces with the registrant for the provisioning of 237 objects, such as domain names and contacts, and with the 238 registries to satisfy the registrant's provisioning requests. A 239 registrar may directly interface with the registrant or may 240 indirectly interface with the registrant, typically through one 241 or more resellers. Implementing a transfer using secure 242 authorization information extends through the registrar's 243 reseller channel up to the direct interface with the registrant. 244 The registrar's interface with the registries uses EPP. The 245 registrar's interface with its reseller channel or the registrant 246 is registrar-specific. In the EPP RFCs, the registrar is 247 referred to as the "client", since EPP is the protocol used 248 between the registrar and the registry. The sponsoring registrar 249 is the authorized registrar to manage objects on behalf of the 250 registrant. A non-sponsoring registrar is not authorized to 251 manage objects on behalf of the registrant. A transfer of an 252 object's sponsorship is from one registrar, referred to as the 253 losing registrar, to another registrar, referred to as the 254 gaining registrar. 255 "registry": [RFC8499] defines the registry as "the administrative 256 operation of a zone that allows registration of names within the 257 zone". The registry typically interfaces with the registrars 258 over EPP and generally does not interact directly with the 259 registrant. In the EPP RFCs, the registry is referred to as the 260 "server", since EPP is the protocol used between the registrar 261 and the registry. The registry has a record of the sponsoring 262 registrar for each object and provides the mechanism (over EPP) 263 to coordinate a transfer of an object's sponsorship between 264 registrars. 266 3. Signaling Client and Server Support 268 This document does not define new protocol but an operational 269 practice using the existing EPP protocol, where the client and the 270 server can signal support for the operational practice using a 271 namespace URI in the login and greeting extension services. The 272 namespace URI "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer- 273 1.0" is used to signal support for the operational practice. The 274 client includes the namespace URI in an 275 element of the [RFC5730] Command. The server includes the 276 namespace URI in an element of the [RFC5730] 277 Greeting. 279 A client that receives the namespace URI in the server's Greeting 280 extension services can expect the following supported behavior by the 281 server: 283 1. Support an empty authorization information value with a create 284 command. 285 2. Support unsetting authorization information with an update 286 command. 287 3. Support validating authorization information with an info 288 command. 290 4. Support not returning an indication whether the authorization 291 information is set or unset to the non-sponsoring registrar. 292 5. Support returning an empty authorization information value to the 293 sponsoring registrar when the authorization information is set in 294 an info response. 295 6. Support allowing for the passing of a matching non-empty 296 authorization information value to authorize a transfer. 297 7. Support automatically unsetting the authorization information 298 upon a successful completion of transfer. 300 A server that receives the namespace URI in the client's 301 Command extension services, can expect the following supported 302 behavior by the client: 304 1. Support generation of authorization information using a secure 305 random value. 306 2. Support only setting the authorization information when there is 307 a transfer in process. 309 4. Secure Authorization Information 311 The authorization information in the EPP RFCs ([RFC5731] and 312 [RFC5733]) that support transfer use password-based authorization 313 information ([RFC5731] with the element and [RFC5733] 314 with the element). Other EPP objects that support 315 password-based authorization information for transfer can use the 316 Secure Authorization Information defined in this document. For the 317 authorization information to be secure, it must be generated using a 318 strong random value and have a short time-to-live (TTL). The 319 security of the authorization information is defined in the following 320 sections. 322 4.1. Secure Random Authorization Information 324 For authorization information to be secure, it MUST be generated 325 using a secure random value. The authorization information is 326 treated as a password, and the required length L of a password, 327 rounded up to the largest whole number, is based on the size N of the 328 set of characters and the desired entropy H, in the equation L = 329 ROUNDUP(H / log2 N). Given a target entropy, the required length can 330 be calculated after deciding on the set of characters that will be 331 randomized. In accordance with current best practices and noting 332 that the authorization information is a machine-generated value, the 333 implementation SHOULD use at least 128 bits of entropy as the value 334 of H. The lengths below are calculated using that value. 336 Calculation of the required length with 128 bits of entropy and with 337 the set of all printable ASCII characters except space (0x20), which 338 consists of the 94 characters 0x21-0x7E. 340 ROUNDUP(128 / log2 94) =~ ROUNDUP(128 / 6.55) =~ ROUNDUP(19.54) = 20 342 Calculation of the required length with 128 bits of entropy and with 343 the set of case insensitive alphanumeric characters, which consists 344 of 36 characters (a-z A-Z 0-9). 346 ROUNDUP(128 / log2 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25 348 The strength of the random authorization information is dependent on 349 the random number generator. Suitably strong random number 350 generators are available in a wide variety of implementation 351 environments, including the interfaces listed in Sections 7.1.2 and 352 7.1.3 of [RFC4086]. In environments that do not provide interfaces 353 to strong random number generators, the practices defined in 354 [RFC4086] and section 4.7.1 of the NIST Federal Information 355 Processing Standards (FIPS) Publication 140-2 [FIPS-140-2] can be 356 followed to produce random values that will be resistant to attack. 358 4.2. Authorization Information Time-To-Live (TTL) 360 The authorization information SHOULD only be set when there is a 361 transfer in process. This implies that the authorization information 362 has a Time-To-Live (TTL) by which the authorization information is 363 cleared when the TTL expires. The EPP RFCs have no definition of 364 TTL, but since the server supports the setting and unsetting of the 365 authorization information by the sponsoring registrar, the sponsoring 366 registrar can apply a TTL based on client policy. The TTL client 367 policy may be based on proprietary registrar-specific criteria, which 368 provides for a transfer-specific TTL tuned for the particular 369 circumstances of the transaction. The sponsoring registrar will be 370 aware of the TTL and the sponsoring registrar MUST inform the 371 registrant of the TTL when the authorization information is provided 372 to the registrant. 374 4.3. Authorization Information Storage and Transport 376 To protect the disclosure of the authorization information, the 377 following requirements apply: 379 1. The authorization information MUST be stored by the registry 380 using a strong one-way cryptographic hash, with at least a 381 256-bit hash function, such as SHA-256 [FIPS-180-4], and with a 382 per-authorization information random salt, with at least 128 383 bits. 385 2. Empty authorization information MUST be stored as an undefined 386 value that is referred to as a NULL value. The representation of 387 a NULL (undefined) value is dependent on the type of database 388 used. 389 3. The authorization information MUST NOT be stored by the losing 390 registrar. 391 4. The authorization information MUST only be stored by the gaining 392 registrar as a "transient" value in support of the transfer 393 process. 394 5. The plain text version of the authorization information MUST NOT 395 be written to any logs by a registrar or the registry, nor 396 otherwise recorded where it will persist beyond the transfer 397 process. 398 6. All communication that includes the authorization information 399 MUST be over an encrypted channel, such as defined in [RFC5734] 400 for EPP. 401 7. The registrar's interface for communicating the authorization 402 information with the registrant MUST be over an authenticated and 403 encrypted channel. 405 4.4. Authorization Information Matching 407 To support the authorization information TTL, as defined in 408 Section 4.2, the authorization information must have either a set or 409 unset state. Authorization information that is unset is stored with 410 a NULL (undefined) value. Based on the requirement to store the 411 authorization information using a strong one-way cryptographic hash, 412 as defined in Section 4.3, authorization information that is set is 413 stored with a non-NULL hashed value. The empty authorization 414 information is used as input in both the create command (Section 5.1) 415 and the update command (Section 5.2) to define the unset state. The 416 matching of the authorization information in the info command 417 (Section 5.3) and the transfer request command (Section 5.4) is based 418 on the following rules: 420 1. Any input authorization information value MUST NOT match an unset 421 authorization information value. This includes empty 422 authorization information, such as or 423 in [RFC5731], and non-empty authorization information, such as 424 2fooBAR in [RFC5731]. 425 2. An empty input authorization information value MUST NOT match any 426 set authorization information value. 427 3. A non-empty input authorization information value MUST be hashed 428 and matched against the set authorization information value, 429 which is stored using the same hash algorithm. 431 5. Create, Transfer, and Secure Authorization Information 433 To secure the transfer process using secure authorization 434 information, as defined in Section 4, the client and server need to 435 implement steps where the authorization information is set only when 436 a transfer is actively in process and ensure that the authorization 437 information is stored securely and transported only over secure 438 channels. The steps in management of the authorization information 439 for transfers include: 441 1. Registrant requests to register the object with the registrar. 442 Registrar sends the create command, with an empty authorization 443 information value, to the registry, as defined in Section 5.1. 444 2. Registrant requests from the losing registrar the authorization 445 information to provide to the gaining registrar. 446 3. Losing registrar generates a secure random authorization 447 information value, sends it to the registry as defined in 448 Section 5.2, and provides it to the registrant. 449 4. Registrant provides the authorization information value to the 450 gaining registrar. 451 5. Gaining registrar optionally verifies the authorization 452 information with the info command to the registry, as defined in 453 Section 5.3. 454 6. Gaining registrar sends the transfer request with the 455 authorization information to the registry, as defined in 456 Section 5.4. 457 7. If the transfer successfully completes, the registry 458 automatically unsets the authorization information; otherwise the 459 losing registrar unsets the authorization information when the 460 TTL expires, as defined in Section 5.2. 462 The following sections outline the practices of the EPP commands and 463 responses between the registrar and the registry that supports secure 464 authorization information for transfer. 466 5.1. Create Command 468 For a create command, the registry MUST allow for the passing of an 469 empty authorization information value and MAY disallow for the 470 passing of a non-empty authorization information value. By having an 471 empty authorization information value on create, the object is 472 initially not in the transfer process. Any EPP object extension that 473 supports setting the authorization information with a 474 "eppcom:pwAuthInfoType" element can have an empty authorization 475 information value passed. Examples of such extensions are [RFC5731] 476 and [RFC5733]. 478 Example of passing an empty authorization information value in an 479 [RFC5731] domain name create command: 481 C: 482 C: 483 C: 484 C: 485 C: 487 C: example.com 488 C: 489 C: 490 C: 491 C: 492 C: 493 C: ABC-12345 494 C: 495 C: 497 Example of passing an empty authorization information value in an 498 [RFC5733] contact create command: 500 C: 501 C: 502 C: 503 C: 504 C: 506 C: sh8013 507 C: 508 C: John Doe 509 C: 510 C: Dulles 511 C: US 512 C: 513 C: 514 C: jdoe@example.com 515 C: 516 C: 517 C: 518 C: 519 C: 520 C: ABC-12345 521 C: 522 C: 524 5.2. Update Command 526 For an update command, the registry MUST allow for the setting and 527 unsetting of the authorization information. The registrar sets the 528 authorization information by first generating a strong, random 529 authorization information value, based on Section 4.1, and setting it 530 in the registry in the update command. The importance of generating 531 strong authorization information values cannot be overstated: secure 532 transfers are very important to the Internet to mitigate damage in 533 the form of theft, fraud, and other abuse. It is critical that 534 registrars only use strong, randomly generated authorization 535 information values. 537 Because of this, registries may validate the randomness of the 538 authorization information based on the length and character set 539 required by the registry. For example, validating an authorization 540 value contains a combination of upper-case, lower-case, and non- 541 alphanumeric characters, in an attempt to assess the strength of the 542 value, and return an EPP error result of 2202 if the check fails. 544 Such checks are, by their nature, heuristic and imperfect, and may 545 identify well-chosen authorization information values as being not 546 sufficiently strong. Registrars, therefore, must be prepared for an 547 error response of 2202, "Invalid authorization information", and 548 respond by generating a new value and trying again, possibly more 549 than once. 551 Often, the registrar has the "clientTransferProhibited" status set, 552 so to start the transfer process, the "clientTransferProhibited" 553 status needs to be removed, and the strong, random authorization 554 information value needs to be set. The registrar MUST define a time- 555 to-live (TTL), as defined in Section 4.2, where if the TTL expires 556 the registrar will unset the authorization information. 558 Example of removing the "clientTransferProhibited" status and setting 559 the authorization information in an [RFC5731] domain name update 560 command: 562 C: 563 C: 564 C: 565 C: 566 C: 568 C: example.com 569 C: 570 C: 571 C: 572 C: 573 C: 574 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP 575 C: 576 C: 577 C: 578 C: 579 C: 580 C: ABC-12345-XYZ 581 C: 582 C: 584 When the registrar-defined TTL expires, the sponsoring registrar MUST 585 cancel the transfer process by unsetting the authorization 586 information value and MAY add back statuses like the 587 "clientTransferProbited" status. Any EPP object extension that 588 supports setting the authorization information with a 589 "eppcom:pwAuthInfoType" element, can have an empty authorization 590 information value passed. Examples of such extensions are [RFC5731] 591 and [RFC5733]. Setting an empty authorization information value 592 unsets the authorization information. [RFC5731] supports an explicit 593 mechanism of unsetting the authorization information, by passing the 594 authorization information value. The registry MUST 595 support unsetting the authorization information by accepting an empty 596 authorization information value and accepting an explicit unset 597 element if it is supported by the object extension. 599 Example of adding the "clientTransferProhibited" status and unsetting 600 the authorization information explicitly in an [RFC5731] domain name 601 update command: 603 C: 604 C: 605 C: 606 C: 607 C: 609 C: example.com 610 C: 611 C: 612 C: 613 C: 614 C: 615 C: 616 C: 617 C: 618 C: 619 C: 620 C: ABC-12345-XYZ 621 C: 622 C: 624 Example of unsetting the authorization information with an empty 625 authorization information value in an [RFC5731] domain name update 626 command: 628 C: 629 C: 630 C: 631 C: 632 C: 634 C: example.com 635 C: 636 C: 637 C: 638 C: 639 C: 640 C: 641 C: 642 C: 643 C: 644 C: 645 C: ABC-12345-XYZ 646 C: 647 C: 648 Example of unsetting the authorization information with an empty 649 authorization information value in an [RFC5733] contact update 650 command: 652 C: 653 C: 654 C: 655 C: 656 C: 658 C: sh8013 659 C: 660 C: 661 C: 662 C: 663 C: 664 C: 665 C: 666 C: ABC-12345-XYZ 667 C: 668 C: 670 5.3. Info Command and Response 672 For an info command, the registry MUST allow for the passing of a 673 non-empty authorization information value for verification. The 674 gaining registrar can pre-verify the authorization information 675 provided by the registrant prior to submitting the transfer request 676 with the use of the info command. The registry compares the hash of 677 the passed authorization information with the hashed authorization 678 information value stored for the object. When the authorization 679 information is not set or the passed authorization information does 680 not match the previously set value, the registry MUST return an EPP 681 error result code of 2202 [RFC5730]. 683 Example of passing a non-empty authorization information value in an 684 [RFC5731] domain name info command to verify the authorization 685 information value: 687 C: 688 C: 689 C: 690 C: 691 C: 693 C: example.com 694 C: 695 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP 696 C: 697 C: 698 C: 699 C: 700 C: ABC-12345 701 C: 702 C: 704 The info response in object extensions, such as [RFC5731] and 705 [RFC5733], MUST NOT include the optional authorization information 706 element with a non-empty authorization value. The authorization 707 information is stored as a hash in the registry, so returning the 708 plain text authorization information is not possible, unless a valid 709 plain text authorization information is passed in the info command. 710 The registry MUST NOT return any indication of whether the 711 authorization information is set or unset to the non-sponsoring 712 registrar by not returning the authorization information element in 713 the response. The registry MAY return an indication to the 714 sponsoring registrar that the authorization information is set by 715 using an empty authorization information value. The registry MAY 716 return an indication to the sponsoring registrar that the 717 authorization information is unset by not returning the authorization 718 information element. 720 Example of returning an empty authorization information value in an 721 [RFC5731] domain name info response to indicate to the sponsoring 722 registrar that the authorization information is set: 724 S: 725 S: 726 S: 727 S: 728 S: Command completed successfully 729 S: 730 S: 731 S: 733 S: example.com 734 S: EXAMPLE1-REP 735 S: 736 S: ClientX 737 S: 738 S: 739 S: 740 S: 741 S: 742 S: 743 S: ABC-12345 744 S: 54322-XYZ 745 S: 746 S: 747 S: 749 5.4. Transfer Request Command 751 For a Transfer Request Command, the registry MUST allow for the 752 passing of a non-empty authorization information value to authorize a 753 transfer. The registry compares the hash of the passed authorization 754 information with the hashed authorization information value stored 755 for the object. When the authorization information is not set or the 756 passed authorization information does not match the previously set 757 value, the registry MUST return an EPP error result code of 2202 758 [RFC5730]. Whether the transfer occurs immediately or is pending is 759 up to server policy. When the transfer occurs immediately, the 760 registry MUST return the EPP success result code of 1000 and when the 761 transfer is pending, the registry MUST return the EPP success result 762 code of 1001. The losing registrar MUST be informed of a successful 763 transfer request using an EPP poll message. 765 Example of passing a non-empty authorization information value in an 766 [RFC5731] domain name transfer request command to authorize the 767 transfer: 769 C: 770 C: 771 C: 772 C: 773 C: 775 C: example1.com 776 C: 777 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP 778 C: 779 C: 780 C: 781 C: 782 C: ABC-12345 783 C: 784 C: 786 Upon successful completion of the transfer, the registry MUST 787 automatically unset the authorization information. If the transfer 788 request is not submitted within the time-to-live (TTL) (Section 4.2) 789 or the transfer is cancelled or rejected, the registrar MUST unset 790 the authorization information as defined in Section 5.2. 792 6. Transition Considerations 794 The goal of the transition considerations to the practice defined in 795 this document, referred to as the Secure Authorization Information 796 Model, is to minimize the impact to the registrars by supporting 797 incremental steps of adoption. The transition steps are dependent on 798 the starting point of the registry. Registries may have different 799 starting points, since some of the elements of the Secure 800 Authorization Information Model may have already been implemented. 801 The considerations assume a starting point, referred to as the 802 Classic Authorization Information Model, that have the following 803 steps in the management of the authorization information for 804 transfers: 806 1. Registrant requests to register the object with the registrar. 807 Registrar sends the create command, with a non-empty 808 authorization information value, to the registry. The registry 809 stores the authorization information as an encrypted value and 810 requires a non-empty authorization information value for the life 811 of the object. The registrar may store the long-lived 812 authorization information. 813 2. At the time of transfer, Registrant requests from the losing 814 registrar the authorization information to provide to the gaining 815 registrar. 817 3. Losing registrar retrieves the locally stored authorization 818 information or queries the registry for authorization information 819 using the info command, and provides it to the registrant. If 820 the registry is queried, the authorization information is 821 decrypted and the plain text authorization information is 822 returned in the info response to the registrar. 823 4. Registrant provides the authorization information value to the 824 gaining registrar. 825 5. Gaining registrar optionally verifies the authorization 826 information with the info command to the registry, by passing the 827 authorization information in the info command to the registry. 828 6. Gaining registrar sends the transfer request with the 829 authorization information to the registry. The registry will 830 decrypt the stored authorization information to compare to the 831 passed authorization information. 832 7. If the transfer successfully completes, the authorization 833 information is not touched by the registry and may be updated by 834 the gaining registrar using the update command. If the transfer 835 is cancelled or rejected, the losing registrar may reset the 836 authorization information using the update command. 838 The gaps between the Classic Authorization Information Model and the 839 Secure Authorization Information Model include: 841 1. Registry requirement for a non-empty authorization information 842 value on create and for the life of the object versus the 843 authorization information not being set on create and only being 844 set when a transfer is in process. 845 2. Registry not allowing the authorization information to be unset 846 versus supporting the authorization to be unset in the update 847 command. 848 3. Registry storing the authorization information as an encrypted 849 value versus as a hashed value. 850 4. Registry support for returning the authorization information 851 versus not returning the authorization information in the info 852 response. 853 5. Registry not touching the authorization information versus the 854 registry automatically unsetting the authorization information 855 upon a successful transfer. 856 6. Registry may validate a shorter authorization information value 857 using password complexity rules versus validating the randomness 858 of a longer authorization information value that meets the 859 required bits of entropy. 861 The transition can be handled in the three phases defined in the sub- 862 sections Section 6.1, Section 6.2, Section 6.3. 864 6.1. Transition Phase 1 - Features 866 The goal of the "Transition Phase 1 - Features" is to implement the 867 needed features in EPP so that the registrar can optionally implement 868 the Secure Authorization Information Model. The features to 869 implement are broken out by the command and responses below: 871 Create Command: Change the create command to make the authorization 872 information optional, by allowing both a non-empty value and an 873 empty value. This enables a registrar to optionally create 874 objects without an authorization information value, as defined in 875 Section 5.1. 876 Update Command: Change the update command to allow unsetting the 877 authorization information, as defined in Section 5.2. This 878 enables the registrar to optionally unset the authorization 879 information when the TTL expires or when the transfer is cancelled 880 or rejected. 881 Transfer Approve Command and Transfer Auto-Approve: Change the 882 transfer approve command and the transfer auto-approve to 883 automatically unset the authorization information. This sets the 884 default state of the object to not have the authorization 885 information set. The registrar implementing the Secure 886 Authorization Information Model will not set the authorization 887 information for an inbound transfer and the registrar implementing 888 the Classic Authorization Information Model will set the new 889 authorization information upon the successful transfer. 890 Info Response: Change the info command to not return the 891 authorization information in the info response, as defined in 892 Section 5.3. This sets up the implementation of "Transition Phase 893 2 - Storage", since the dependency in returning the authorization 894 information in the info response will be removed. This feature is 895 the only one that is not an optional change to the registrar that 896 has the potential of breaking the client, so it's recommended that 897 the registry provide notice of the change. 898 Info Command and Transfer Request: Change the info command and the 899 transfer request to ensure that a registrar cannot get an 900 indication that the authorization information is set or not set by 901 returning the EPP error result code of 2202 when comparing a 902 passed authorization to a non-matching set authorization 903 information value or an unset value. 905 6.2. Transition Phase 2 - Storage 907 The goal of the "Transition Phase 2 - Storage" is to transition the 908 registry to use hashed authorization information instead of encrypted 909 authorization information. There is no direct impact to the 910 registrars, since the only visible indication that the authorization 911 information has been hashed is by not returning the set authorization 912 information in the info response, which is addressed in Transition 913 Phase 1 - Features (Section 6.1). There are three steps to 914 transition the authorization information storage, which includes: 916 Hash New Authorization Information Values: Change the create command 917 and the update command to hash instead of encrypting the 918 authorization information. 919 Supporting Comparing Against Encrypted and Hashed Authorization 920 Information: Change the info command and the transfer request 921 command to be able to compare a passed authorization information 922 value with either a hashed or encrypted authorization information 923 value. This requires that the stored values are self-identifying 924 as being in hashed or encrypted form. 925 Hash Existing Encrypted Authorization Information Values: Convert 926 the encrypted authorization information values stored in the 927 registry database to hashed values. The update is not a visible 928 change to the registrar. The conversion can be done over a period 929 of time depending on registry policy. 931 6.3. Transition Phase 3 - Enforcement 933 The goal of the "Transition Phase 3 - Enforcement" is to complete the 934 implementation of the "Secure Authorization Information Model", by 935 enforcing the following: 937 Disallow Authorization Information on Create Command: Change the 938 create command to not allow for the passing of a non-empty 939 authorization information value. This behavior has the potential 940 of breaking the client, so it's recommended that the registry 941 provide notice of the change. 942 Validate the Strong Random Authorization Information: Change the 943 validation of the authorization information in the update command 944 to ensure at least 128 bits of entropy. 946 7. IANA Considerations 948 7.1. XML Namespace 950 This document uses URNs to describe XML namespaces conforming to a 951 registry mechanism described in [RFC3688]. The following URI 952 assignment is requested of IANA: 954 Registration request for the secure authorization information for 955 transfer namespace: 957 URI: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0 958 Registrant Contact: IESG 959 XML: None. Namespace URIs do not represent an XML specification. 961 7.2. EPP Extension Registry 963 The EPP operational practice described in this document should be 964 registered by the IANA in the EPP Extension Registry described in 965 [RFC7451]. The details of the registration are as follows: 967 Name of Extension: "Extensible Provisioning Protocol (EPP) Secure 968 Authorization Information for Transfer" 970 Document status: Standards Track 972 Reference: (insert reference to RFC version of this document) 974 Registrant Name and Email Address: IESG, 976 TLDs: Any 978 IPR Disclosure: None 980 Status: Active 982 Notes: None 984 8. Implementation Status 986 Note to RFC Editor: Please remove this section and the reference to 987 RFC 7942 [RFC7942] before publication. 989 This section records the status of known implementations of the 990 protocol defined by this specification at the time of posting of this 991 Internet-Draft, and is based on a proposal described in RFC 7942 992 [RFC7942]. The description of implementations in this section is 993 intended to assist the IETF in its decision processes in progressing 994 drafts to RFCs. Please note that the listing of any individual 995 implementation here does not imply endorsement by the IETF. 996 Furthermore, no effort has been spent to verify the information 997 presented here that was supplied by IETF contributors. This is not 998 intended as, and must not be construed to be, a catalog of available 999 implementations or their features. Readers are advised to note that 1000 other implementations may exist. 1002 According to RFC 7942 [RFC7942], "this will allow reviewers and 1003 working groups to assign due consideration to documents that have the 1004 benefit of running code, which may serve as evidence of valuable 1005 experimentation and feedback that have made the implemented protocols 1006 more mature. It is up to the individual working groups to use this 1007 information as they see fit". 1009 8.1. Verisign EPP SDK 1011 Organization: Verisign Inc. 1013 Name: Verisign EPP SDK 1015 Description: The Verisign EPP SDK includes both a full client 1016 implementation and a full server stub implementation of draft-ietf- 1017 regext-secure-authinfo-transfer. 1019 Level of maturity: Development 1021 Coverage: All aspects of the protocol are implemented. 1023 Licensing: GNU Lesser General Public License 1025 Contact: jgould@verisign.com 1027 URL: https://www.verisign.com/en_US/channel-resources/domain- 1028 registry-products/epp-sdks 1030 8.2. RegistryEngine EPP Service 1032 Organization: CentralNic 1034 Name: RegistryEngine EPP Service 1036 Description: Generic high-volume EPP service for gTLDs, ccTLDs and 1037 SLDs 1039 Level of maturity: Deployed in CentralNic's production environment as 1040 well as two other gTLD registry systems, and two ccTLD registry 1041 systems. 1043 Coverage: Authorization Information is "write only" in that the 1044 registrars can set the Authorization Information, but not get the 1045 Authorization Information in the Info Response. 1047 Licensing: Proprietary In-House software 1049 Contact: epp@centralnic.com 1050 URL: https://www.centralnic.com 1052 9. Security Considerations 1054 Section 4.1 defines the use a secure random value for the generation 1055 of the authorization information. The client SHOULD choose a length 1056 and set of characters that results in at least 128 bits of entropy. 1058 Section 4.2 defines the use of an authorization information Time-To- 1059 Live (TTL). The registrar SHOULD only set the authorization 1060 information during the transfer process by the server support for 1061 setting and unsetting the authorization information. The TTL value 1062 is up to registrar policy and the sponsoring registrar MUST inform 1063 the registrant of the TTL when providing the authorization 1064 information to the registrant. 1066 Section 4.3 defines the storage and transport of authorization 1067 information. The losing registrar MUST NOT store the authorization 1068 information and the gaining registrar MUST only store the 1069 authorization information as a "transient" value during the transfer 1070 process, where the authorization information MUST NOT be stored after 1071 the end of the transfer process. The registry MUST store the 1072 authorization information using a one-way cryptographic hash of at 1073 least 256 bits and with a per-authorization information random salt, 1074 with at least 128 bits. All communication that includes the 1075 authorization information MUST be over an encrypted channel. The 1076 plain text authorization information MUST NOT be written to any logs 1077 by the registrar or the registry. 1079 Section 4.4 defines the matching of the authorization information 1080 values. The registry stores an unset authorization information as a 1081 NULL (undefined) value to ensure that an empty input authorization 1082 information never matches it. The method used to define a NULL 1083 (undefined) value is database specific. 1085 10. Acknowledgements 1087 The authors wish to thank the following persons for their feedback 1088 and suggestions: Michael Bauland, Martin Casanova, Scott Hollenbeck, 1089 Benjamin Kaduk, Jody Kolker, Barry Leiba, Patrick Mevzek, Matthew 1090 Pozun, Srikanth Veeramachaneni, and Ulrich Wisser. 1092 11. References 1094 11.1. Normative References 1096 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1097 Requirement Levels", BCP 14, RFC 2119, 1098 DOI 10.17487/RFC2119, March 1997, 1099 . 1101 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1102 DOI 10.17487/RFC3688, January 2004, 1103 . 1105 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1106 "Randomness Requirements for Security", BCP 106, RFC 4086, 1107 DOI 10.17487/RFC4086, June 2005, 1108 . 1110 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1111 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1112 . 1114 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1115 Domain Name Mapping", STD 69, RFC 5731, 1116 DOI 10.17487/RFC5731, August 2009, 1117 . 1119 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1120 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 1121 August 2009, . 1123 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1124 Transport over TCP", STD 69, RFC 5734, 1125 DOI 10.17487/RFC5734, August 2009, 1126 . 1128 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1129 Code: The Implementation Status Section", BCP 205, 1130 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1131 . 1133 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 1134 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 1135 May 2017, . 1137 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1138 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1139 January 2019, . 1141 11.2. Informative References 1143 [FIPS-140-2] 1144 National Institute of Standards and Technology, U.S. 1145 Department of Commerce, "NIST Federal Information 1146 Processing Standards (FIPS) Publication 140-2", May 2001, 1147 . 1150 [FIPS-180-4] 1151 National Institute of Standards and Technology, U.S. 1152 Department of Commerce, "Secure Hash Standard, NIST 1153 Federal Information Processing Standards (FIPS) 1154 Publication 180-4", August 2015, 1155 . 1158 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1159 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1160 February 2015, . 1162 Appendix A. Change History 1164 A.1. Change from 00 to 01 1166 1. Filled in the "Implementation Status" section with the inclusion 1167 of the "Verisign EPP SDK" and "RegistryEngine EPP Service" 1168 implementations. 1169 2. Made small wording corrections based on private feedback. 1170 3. Added content to the "Acknowledgements" section. 1172 A.2. Change from 01 to 02 1174 1. Revised the language used for the storage of the authorization 1175 information based on the feedback from Patrick Mevzek and Jody 1176 Kolker. 1178 A.3. Change from 02 to 03 1180 1. Updates based on the feedback from the interim REGEXT meeting 1181 held at ICANN-66: 1182 1. Section 3.3, include a reference to the hash algorithm to 1183 use. Broke the requirements into a list and included a the 1184 reference the text ', with at least a 256-bit hash function, 1185 such as SHA-256'. 1186 2. Add a Transition Considerations section to cover the 1187 transition from the classic authorization information 1188 security model in the EPP RFCs to the model defined in the 1189 document. 1191 3. Add a statement to the Introduction that elements of the 1192 practice can be used for purposes other than transfer, but 1193 with a caveat. 1194 2. Updates based on the review by Michael Bauland, that include: 1195 1. In section 2, change 'there are three actors' to 'there are 1196 three types of actors' to cover the case with transfers that 1197 has two registrar actors (losing and gaining). 1198 2. In section 3.1, change the equations equals to be 1199 approximately equal by using '=~' instead of '=', where 1200 applicable. 1201 3. In section 3.3, change 'MUST be over an encrypted channel, 1202 such as RFC5734' to 'MUST be over an encrypted channel, such 1203 as defined in RFC5734'. 1204 4. In section 4.1, remove the optional RFC 5733 elements from 1205 the contact create, which includes the , 1206 , , , 1207 , , and elements. 1208 5. In section 4.2, changed 'Example of unsetting the 1209 authorization information explicitly in an [RFC5731] domain 1210 name update command.' to 'Example of adding the 1211 "clientTransferProhibited" status and unsetting the 1212 authorization information explicitly in an [RFC5731] domain 1213 name update command.' 1214 6. In section 4.3, cover a corner case of the ability to return 1215 the authorization information when it's passed in the info 1216 command. 1217 7. In section 4.4, change 'If the transfer does not complete 1218 within the time-to-live (TTL)' to 'If the transfer is not 1219 initiated within the time-to-live (TTL)', since the TTL is 1220 the time between setting the authorization information and 1221 when it's successfully used in a transfer request. Added the 1222 case of unsetting the authorization information when the 1223 transfer is cancelled or rejected. 1224 3. Updates based on the authorization information messages by Martin 1225 Casanova on the REGEXT mailing list, that include: 1226 1. Added section 3.4 'Authorization Information Matching' to 1227 clarify how the authorization information is matched, when 1228 there is set and unset authorization information in the 1229 database and empty and non-empty authorization information 1230 passed in the info and transfer commands. 1231 2. Added support for signaling that the authorization 1232 information is set or unset to the sponsoring registrar with 1233 the inclusion of an empty authorization information element 1234 in the response to indicate that the authorization 1235 information is set and the exclusion of the authorization 1236 information element in the response to indicate that the 1237 authorization information is unset. 1239 4. Made the capitalization of command and response references 1240 consistent by uppercasing section and item titles and lowercasing 1241 references elsewhere. 1243 A.4. Change from 03 to REGEXT 00 1245 1. Changed to regext working group draft by changing draft-gould- 1246 regext-secure-authinfo-transfer to draft-ietf-regext-secure- 1247 authinfo-transfer. 1249 A.5. Change from REGEXT 00 to REGEXT 01 1251 1. Added the "Signaling Client and Server Support" section to 1252 describe the mechanism to signal support for the BCP by the 1253 client and the server. 1254 2. Added the "IANA Considerations" section with the registration of 1255 the secure authorization for transfer XML namespace and the 1256 registration of the EPP Best Current Practice (BCP) in the EPP 1257 Extension Registry. 1259 A.6. Change from REGEXT 01 to REGEXT 02 1261 1. Added inclusion of random salt for the hashed authorization 1262 information, based on feedback from Ulrich Wisser. 1263 2. Added clarification that the representation of a NULL (undefined) 1264 value is dependent on the type of database, based on feedback 1265 from Patrick Mevzek. 1266 3. Filled in the Security Considerations section. 1268 A.7. Change from REGEXT 02 to REGEXT 03 1270 1. Updated the XML namespace to urn:ietf:params:xml:ns:epp:secure- 1271 authinfo-transfer-1.0, which removed bcp from the namespace and 1272 bumped the version from 0.1 and 1.0. Inclusion of bcp in the XML 1273 namespace was discussed at the REGEXT interim meeting. 1274 2. Replaced Auhtorization with Authorization based on a review by 1275 Jody Kolker. 1277 A.8. Change from REGEXT 03 to REGEXT 04 1279 1. Converted from xml2rfc v2 to v3. 1280 2. Updated Acknowledgements to match the approach taken by the RFC 1281 Editor with draft-ietf-regext-login-security. 1282 3. Changed from Best Current Practice (BCP) to Standards Track based 1283 on mailing list discussion. 1285 A.9. Change from REGEXT 04 to REGEXT 05 1286 1. Fixed IDNITS issues, including moving RFC7451 to Informative 1287 References section. 1289 A.10. Change from REGEXT 05 to REGEXT 06 1291 Updates based on the Barry Leiba (AD) feedback: 1293 1. Simplified the abstract based on the proposal provided. 1294 2. In the Introduction, split the first paragraph by starting a new 1295 paragraph at "This document". 1296 3. In section 1.1, updated to use the new BCP 14 boilerplate and 1297 add a normative reference to RFC 8174. 1298 4. In section 4, Updated the phrasing to "For the authorization 1299 information to be secure it must be generated using a strong 1300 random value and have a short time-to-live (TTL).". 1301 5. In section 4.1, removed the first two unnecessary calculations 1302 and condensed the introduction of the section. 1303 6. In section 4.1, added the use of the normative SHOULD for use of 1304 at least 128 bits of entropy. 1305 7. Added an informative reference to FIPS 180-4 for the SHA-256 1306 references. 1307 8. Normalized the way that the "empty and non-empty authorization 1308 information values" are referenced, which a few exceptions. 1309 9. In section 4, revised the first sentence to explicitly reference 1310 the use of the and elements for 1311 password-based authorization information. 1312 10. In section 4.4, revised the language associated with the storage 1313 of the authorization information to be cleaner. 1314 11. In section 4.4, added "set" in the sentence "An empty input 1315 authorization information value MUST NOT match any set 1316 authorization information value." 1317 12. In section 5.1 and 5.2, clarified the references to RFC5731 and 1318 RFC5733 as examples of object extensions that use the 1319 "eppcom:pwAuthInfoType" element. 1320 13. In section 5.2, updated language for the validation of the 1321 randomness of the authorization information, based on an offline 1322 review by Barry Leiba, Benjamin Kaduk, and Roman Danyliw. 1323 14. In section 9, changed "49 bits of entropy" to "128 bits of 1324 entropy". 1326 In section 3, replaced the reference to BCP with operational 1327 practice, since the draft is not defined as a BCP. 1329 A.11. Change from REGEXT 06 to REGEXT 07 1331 1. Updates based on the Lars Eggert feedback: 1333 1. Updated Section 1, Paragraph 4 to read "The operational 1334 practice will require the client to not store the 1335 authorization information and". 1336 2. Updated each of the example references to end with a colon 1337 instead of a period. 1338 3. Updated Section 1, Paragraph 3 to read "provide secure 1339 authorization information used for transfers." 1340 4. Updated Section 3, Paragraph 3 to read "extension services 1341 can expect". 1342 5. Updated Section 4, Paragraph 2 to read "authorization 1343 information to be secure, it must". 1344 6. Updated Section 4.2, Paragraph 2 to read "authorization 1345 information by the sponsoring registrar, the". 1346 7. Updated Section 4.2, Paragraph 2 to read "proprietary 1347 registrar-specific criteria, which". 1348 8. Updated Section 4.3, Paragraph 3 to read "256-bit hash 1349 function, such as SHA-256". 1350 9. Updated Section 4.3, Paragraph 3 to read "a NULL (undefined) 1351 value". 1352 10. Updated Section 5, Paragraph 2 to read "To secure the 1353 transfer process using secure authorization". 1354 11. Updated Section 5.2, Paragraph 6 to read "Often, the 1355 registrar has the "clientTransferProhibited" status set". 1356 12. Updated Section 5.2, Paragraph 9 to read "MUST cancel cancel 1357 the transfer process by unsetting the authorization 1358 information value and MAY add back statuses". 1359 13. Updated Section 5.2, Paragraph 9 to read 1360 ""eppcom:pwAuthInfoType" element can have". 1362 2. Updated the first sentence of the abstract and introduction based 1363 on the Rob Wilton feedback to help non-EPP readers on the what 1364 and the who for transfers. 1366 3. Removed the duplicate first paragraph of section 5.2 based on 1367 feedback from Francesca Palombini. 1369 4. Updates based on the Benjamin Kaduk feedback: 1371 1. Added the second paragraph in the Introduction to provide 1372 high-level motivation for the work. 1373 2. Updated Section 1, changed "in any way" to "in any 1374 substantial way". 1375 3. Updated Section 1 by adding the sentence "All of these 1376 features are compatible with the EPP RFCs, though not 1377 mandatory to implement." for the "Short-Lived Authorization 1378 Information". 1380 4. Updated the description of "Short-Lived Authorization 1381 Information" in Section 1 to reference section 2.6 of 1382 RFC5731 and change in nature of the authorization 1383 information. 1384 5. Updated Section 4.1, Paragraph 1 and 2 were merged with 1385 modified language proposed by Benjamin Kaduk, which included 1386 removing the reference to RFC4086 for length and entropy. 1387 6. Updated rule #1 of Section 4.1 to add a second clarifying 1388 sentence for what is meant by input authorization 1389 information. 1390 7. Updated Section 4.1 by replacing the last paragraph "The 1391 strength of the random..." with a revised version. 1392 8. Updated "retrieves the stored authorization information 1393 locally" with "retrieves the locally stored authorization 1394 information". 1395 9. Updated Section 6.1 to include the recommendation that the 1396 registry provide notice of the Info Response change. 1397 10. Updated Section 6.2 to include the sentence "This requires 1398 that the stored values are self-identifying as being in 1399 hashed or encrypted form" for the "Supporting Comparing 1400 Against Encrypted and Hashed Authorization Information" 1401 step. 1402 11. Updated Section 6.3 to include the recommendation that the 1403 registry provide notice of the Create Command change. 1404 12. Updated "written to any logs by the registrar or the 1405 registry" to "written to any logs by a registrar or the 1406 registry" to cover both the losing and the gaining 1407 registrar. 1408 13. Updated references to "with a random salt" to "with a per- 1409 authorization information random salt, with at least 128 1410 bits" to address sharing of salts and the size of the salts. 1411 14. Updated the first paragraph of Section 9 to remove the 1412 reference to defining a server policy for the length and set 1413 of characters that are included in the randomization to 1414 target the target entropy level. 1415 15. Updated Section 9 by removing the sentence "A random number 1416 generator (RNG) is preferable over the use of a pseudorandom 1417 number generator (PRNG) when creating the authorization 1418 information value." 1419 16. Changed FIPS-140-2 from a normative reference to an 1420 informative reference. 1422 Authors' Addresses 1423 James Gould 1424 VeriSign, Inc. 1425 12061 Bluemont Way 1426 Reston, VA 20190 1427 United States of America 1429 Email: jgould@verisign.com 1430 URI: http://www.verisign.com 1432 Richard Wilhelm 1433 VeriSign, Inc. 1434 12061 Bluemont Way 1435 Reston, VA 20190 1436 United States of America 1438 Email: rwilhelm@verisign.com 1439 URI: http://www.verisign.com