idnits 2.17.1 draft-ietf-regext-secure-authinfo-transfer-06.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 (8 March 2021) is 1144 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) -- Possible downref: Non-RFC (?) normative reference: ref. 'FIPS-140-2' ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gould 3 Internet-Draft R. Wilhelm 4 Intended status: Standards Track VeriSign, Inc. 5 Expires: 9 September 2021 8 March 2021 7 Extensible Provisioning Protocol (EPP) Secure Authorization Information 8 for Transfer 9 draft-ietf-regext-secure-authinfo-transfer-06 11 Abstract 13 The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the 14 use of authorization information to authorize a transfer. Object- 15 specific, password-based authorization information (see RFC 5731 and 16 RFC 5733) is commonly used, but raises issues related to the 17 security, complexity, storage, and lifetime of authentication 18 information. This document defines an operational practice, using 19 the EPP RFCs, that leverages the use of strong random authorization 20 information values that are short-lived, not stored by the client, 21 and stored by the server using a cryptographic hash that provides for 22 secure authorization information that can safely be used for object 23 transfers. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on 9 September 2021. 42 Copyright Notice 44 Copyright (c) 2021 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents (https://trustee.ietf.org/ 49 license-info) in effect on the date of publication of this document. 50 Please review these documents carefully, as they describe your rights 51 and restrictions with respect to this document. Code Components 52 extracted from this document must include Simplified BSD License text 53 as described in Section 4.e of the Trust Legal Provisions and are 54 provided without warranty as described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 60 2. Registrant, Registrar, Registry . . . . . . . . . . . . . . . 5 61 3. Signaling Client and Server Support . . . . . . . . . . . . . 6 62 4. Secure Authorization Information . . . . . . . . . . . . . . 7 63 4.1. Secure Random Authorization Information . . . . . . . . . 7 64 4.2. Authorization Information Time-To-Live (TTL) . . . . . . 8 65 4.3. Authorization Information Storage and Transport . . . . . 8 66 4.4. Authorization Information Matching . . . . . . . . . . . 9 67 5. Create, Transfer, and Secure Authorization Information . . . 9 68 5.1. Create Command . . . . . . . . . . . . . . . . . . . . . 10 69 5.2. Update Command . . . . . . . . . . . . . . . . . . . . . 12 70 5.3. Info Command and Response . . . . . . . . . . . . . . . . 15 71 5.4. Transfer Request Command . . . . . . . . . . . . . . . . 17 72 6. Transition Considerations . . . . . . . . . . . . . . . . . . 18 73 6.1. Transition Phase 1 - Features . . . . . . . . . . . . . . 20 74 6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 21 75 6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 21 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 77 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 21 78 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 22 79 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 22 80 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 23 81 8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 23 82 9. Security Considerations . . . . . . . . . . . . . . . . . . . 24 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 24 84 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 85 11.1. Normative References . . . . . . . . . . . . . . . . . . 25 86 11.2. Informative References . . . . . . . . . . . . . . . . . 26 87 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 26 88 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 26 89 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 26 90 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 26 91 A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 28 92 A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 28 93 A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 28 94 A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 28 95 A.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 28 96 A.9. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 29 97 A.10. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 29 98 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 29 100 1. Introduction 102 The Extensible Provisioning Protocol (EPP), in [RFC5730], defines the 103 use of authorization information to authorize a transfer. The 104 authorization information is object-specific and has been defined in 105 the EPP Domain Name Mapping, in [RFC5731], and the EPP Contact 106 Mapping, in [RFC5733], as password-based authorization information. 107 Other authorization mechanisms can be used, but in practice the 108 password-based authorization information has been used at the time of 109 object create, managed with the object update, and used to authorize 110 an object transfer request. What has not been considered is the 111 security of the authorization information that includes the 112 complexity of the authorization information, the time-to-live (TTL) 113 of the authorization information, and where and how the authorization 114 information is stored. 116 This document defines an operational practice, using the EPP RFCs, 117 that leverages the use of strong, random authorization information 118 values that are short-lived, that are not stored by the client, and 119 that are stored by the server using a cryptographic hash to provide, 120 for secure authorization information used for transfers. This 121 operational practice can be used to support transfers of any EPP 122 object, where the domain name object defined in [RFC5731] is used in 123 this document for illustration purposes. Elements of the practice 124 may be used to support the secure use of the authorization 125 information for purposes other than transfer, but any other purposes 126 and the applicable elements are out-of-scope for this document. 128 The overall goal is to have strong, random authorization information 129 values, that are short-lived, and that are either not stored or 130 stored as a cryptographic hash values by the non-responsible parties. 131 In a registrant, registrar, and registry model, the registrant 132 registers the object through the registrar to the registry. The 133 registrant is the responsible party and the registrar and the 134 registry are the non-responsible parties. EPP is a protocol between 135 the registrar and the registry, where the registrar is referred to as 136 the client and the registry is referred to as the server. The 137 following are the elements of the operational practice and how the 138 existing features of the EPP RFCs can be leveraged to satisfy them: 140 "Strong Random Authorization Information": The EPP RFCs define the 141 password-based authorization information value using an XML 142 schema "normalizedString" type, so they don't restrict what can 143 be used in any way. This operational practice defines the 144 recommended mechanism for creating a strong random authorization 145 value, that would be generated by the client. 146 "Short-Lived Authorization Information": The EPP RFCs don't 147 explicitly support short-lived authorization information or a 148 time-to-live (TTL) for authorization information, but there are 149 EPP RFC features that can be leveraged to support short-lived 150 authorization information. If authorization information is set 151 only when there is a transfer in process, the server needs to 152 support an empty authorization information value on create, 153 support setting and unsetting authorization information, and 154 support automatically unsetting the authorization information 155 upon a successful transfer. All of these features can be 156 supported by the EPP RFCs. 157 "Storing Authorization Information Securely": The EPP RFCs don't 158 specify where and how the authorization information is stored in 159 the client or the server, so there are no restrictions to define 160 an operational practice for storing the authorization information 161 securely. The operational practice will not require the client 162 to store the authorization information and will require the 163 server to store the authorization information using a 164 cryptographic hash, with at least a 256-bit hash function such as 165 SHA-256 [FIPS-180-4], and with a random salt. Returning the 166 authorization information set in an EPP info response will not be 167 supported. 169 1.1. Conventions Used in This Document 171 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 172 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 173 "OPTIONAL" in this document are to be interpreted as described in BCP 174 14 [RFC2119] [RFC8174] when, and only when, they appear in all 175 capitals, as shown here. 177 XML is case sensitive. Unless stated otherwise, XML specifications 178 and examples provided in this document MUST be interpreted in the 179 character case presented in order to develop a conforming 180 implementation. 182 In examples, "C:" represents lines sent by a protocol client and "S:" 183 represents lines returned by a protocol server. Indentation and 184 white space in examples are provided only to illustrate element 185 relationships and are not a required feature of this protocol. 187 The examples reference XML namespace prefixes that are used for the 188 associated XML namespaces. Implementations MUST NOT depend on the 189 example XML namespaces and instead employ a proper namespace-aware 190 XML parser and serializer to interpret and output the XML documents. 191 The example namespace prefixes used and their associated XML 192 namespaces include: 194 "domain": urn:ietf:params:xml:ns:domain-1.0 195 "contact": urn:ietf:params:xml:ns:contact-1.0 197 2. Registrant, Registrar, Registry 199 The EPP RFCs refer to client and server, but when it comes to 200 transfers, there are three types of actors that are involved. This 201 document will refer to the actors as registrant, registrar, and 202 registry. [RFC8499] defines these terms formally for the Domain Name 203 System (DNS). The terms are further described below to cover their 204 roles as actors of using the authorization information in the 205 transfer process of any object in the registry, such as a domain name 206 or a contact: 208 "registrant": [RFC8499] defines the registrant as "an individual or 209 organization on whose behalf a name in a zone is registered by 210 the registry". The registrant can be the owner of any object in 211 the registry, such as a domain name or a contact. The registrant 212 interfaces with the registrar for provisioning the objects. A 213 transfer is coordinated by the registrant to transfer the 214 sponsorship of the object from one registrar to another. The 215 authorization information is meant to authenticate the registrant 216 as the owner of the object to the non-sponsoring registrar and to 217 authorize the transfer. 218 "registrar": [RFC8499] defines the registrar as "a service provider 219 that acts as a go-between for registrants and registries". The 220 registrar interfaces with the registrant for the provisioning of 221 objects, such as domain names and contacts, and with the 222 registries to satisfy the registrant's provisioning requests. A 223 registrar may directly interface with the registrant or may 224 indirectly interface with the registrant, typically through one 225 or more resellers. Implementing a transfer using secure 226 authorization information extends through the registrar's 227 reseller channel up to the direct interface with the registrant. 228 The registrar's interface with the registries uses EPP. The 229 registrar's interface with its reseller channel or the registrant 230 is registrar-specific. In the EPP RFCs, the registrar is 231 referred to as the "client", since EPP is the protocol used 232 between the registrar and the registry. The sponsoring registrar 233 is the authorized registrar to manage objects on behalf of the 234 registrant. A non-sponsoring registrar is not authorized to 235 manage objects on behalf of the registrant. A transfer of an 236 object's sponsorship is from one registrar, referred to as the 237 losing registrar, to another registrar, referred to as the 238 gaining registrar. 239 "registry": [RFC8499] defines the registry as "the administrative 240 operation of a zone that allows registration of names within the 241 zone". The registry typically interfaces with the registrars 242 over EPP and generally does not interact directly with the 243 registrant. In the EPP RFCs, the registry is referred to as the 244 "server", since EPP is the protocol used between the registrar 245 and the registry. The registry has a record of the sponsoring 246 registrar for each object and provides the mechanism (over EPP) 247 to coordinate a transfer of an object's sponsorship between 248 registrars. 250 3. Signaling Client and Server Support 252 This document does not define new protocol but an operational 253 practice using the existing EPP protocol, where the client and the 254 server can signal support for the operational practice using a 255 namespace URI in the login and greeting extension services. The 256 namespace URI "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer- 257 1.0" is used to signal support for the operational practice. The 258 client includes the namespace URI in an 259 element of the [RFC5730] Command. The server includes the 260 namespace URI in an element of the [RFC5730] 261 Greeting. 263 A client that receives the namespace URI in the server's Greeting 264 extension services, can expect the following supported behavior by 265 the server: 267 1. Support an empty authorization information value with a create 268 command. 269 2. Support unsetting authorization information with an update 270 command. 271 3. Support validating authorization information with an info 272 command. 273 4. Support not returning an indication whether the authorization 274 information is set or unset to the non-sponsoring registrar. 275 5. Support returning an empty authorization information value to the 276 sponsoring registrar when the authorization information is set in 277 an info response. 278 6. Support allowing for the passing of a matching non-empty 279 authorization information value to authorize a transfer. 280 7. Support automatically unsetting the authorization information 281 upon a successful completion of transfer. 283 A server that receives the namespace URI in the client's 284 Command extension services, can expect the following supported 285 behavior by the client: 287 1. Support generation of authorization information using a secure 288 random value. 289 2. Support only setting the authorization information when there is 290 a transfer in process. 292 4. Secure Authorization Information 294 The authorization information in the EPP RFCs ([RFC5731] and 295 [RFC5733]) that support transfer use password-based authorization 296 information ([RFC5731] with the element and [RFC5733] 297 with the element). Other EPP objects that support 298 password-based authorization information for transfer can use the 299 Secure Authorization Information defined in this document. For the 300 authorization information to be secure it must be generated using a 301 strong random value and have a short time-to-live (TTL). The 302 security of the authorization information is defined in the following 303 sections. 305 4.1. Secure Random Authorization Information 307 For authorization information to be secure, it MUST be generated 308 using a secure random value. The authorization information is 309 treated as a password, where according to [RFC4086] a high-security 310 password must have at least 49 bits of randomness or entropy. The 311 required length L of a password, rounded up to the largest whole 312 number, is based on the set of characters N and the desired entropy 313 H, in the equation L = ROUNDUP(H / log2 N). Given a target entropy, 314 the required length can be calculated after deciding on the set of 315 characters that will be randomized. 317 Considering the age of [RFC4086], the evolution of security 318 practices, and that the authorization information is a machine- 319 generated value, the implementation SHOULD use at least 128 bits of 320 entropy. The lengths are calculated below using that value. 322 Calculation of the required length with 128 bits of entropy and with 323 the set of all printable ASCII characters except space (0x20), which 324 consists of the 94 characters 0x21-0x7E. 326 ROUNDUP(128 / log2 94) =~ ROUNDUP(128 / 6.55) =~ ROUNDUP(19.54) = 20 328 Calculation of the required length with 128 bits of entropy and with 329 the set of case insensitive alphanumeric characters, which consists 330 of 36 characters (a-z A-Z 0-9). 332 ROUNDUP(128 / log2 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25 334 The strength of the random authorization information is dependent on 335 the actual entropy of the underlying random number generator. For 336 the random number generator, the practices defined in [RFC4086] and 337 section 4.7.1 of the NIST Federal Information Processing Standards 338 (FIPS) Publication 140-2 [FIPS-140-2] SHOULD be followed to produce 339 random values that will be resistant to attack. A random number 340 generator (RNG) is preferable over the use of a pseudorandom number 341 generator (PRNG) to reduce the predictability of the authorization 342 information. The more predictable the random number generator is, 343 the lower the true entropy, and the longer the required length for 344 the authorization information. 346 4.2. Authorization Information Time-To-Live (TTL) 348 The authorization information SHOULD only be set when there is a 349 transfer in process. This implies that the authorization information 350 has a Time-To-Live (TTL) by which the authorization information is 351 cleared when the TTL expires. The EPP RFCs have no definition of 352 TTL, but since the server supports the setting and unsetting of the 353 authorization information by the sponsoring registrar, then the 354 sponsoring registrar can apply a TTL based on client policy. The TTL 355 client policy may be based on proprietary registrar-specific criteria 356 which provides for a transfer-specific TTL tuned for the particular 357 circumstances of the transaction. The sponsoring registrar will be 358 aware of the TTL and the sponsoring registrar MUST inform the 359 registrant of the TTL when the authorization information is provided 360 to the registrant. 362 4.3. Authorization Information Storage and Transport 364 To protect the disclosure of the authorization information, the 365 following requirements apply: 367 1. The authorization information MUST be stored by the registry 368 using a strong one-way cryptographic hash, with at least a 369 256-bit hash function such as SHA-256 [FIPS-180-4], and with a 370 random salt. 371 2. Empty authorization information MUST be stored as an undefined 372 value that is referred to as a NULL value. The representation of 373 an NULL (undefined) value is dependent on the type of database 374 used. 375 3. The authorization information MUST NOT be stored by the losing 376 registrar. 377 4. The authorization information MUST only be stored by the gaining 378 registrar as a "transient" value in support of the transfer 379 process. 381 5. The plain text version of the authorization information MUST NOT 382 be written to any logs by the registrar or the registry, nor 383 otherwise recorded where it will persist beyond the transfer 384 process. 385 6. All communication that includes the authorization information 386 MUST be over an encrypted channel, such as defined in [RFC5734] 387 for EPP. 388 7. The registrar's interface for communicating the authorization 389 information with the registrant MUST be over an authenticated and 390 encrypted channel. 392 4.4. Authorization Information Matching 394 To support the authorization information TTL, as defined in 395 Section 4.2, the authorization information must have either a set or 396 unset state. Authorization information that is unset is stored with 397 a NULL (undefined) value. Based on the requirement to store the 398 authorization information using a strong one-way cryptographic hash, 399 as defined in Section 4.3, authorization information that is set is 400 stored with a non-NULL hashed value. The empty authorization 401 information is used as input in both the create command (Section 5.1) 402 and the update command (Section 5.2) to define the unset state. The 403 matching of the authorization information in the info command 404 (Section 5.3) and the transfer request command (Section 5.4) is based 405 on the following rules: 407 1. Any input authorization information value MUST NOT match an unset 408 authorization information value. 409 2. An empty input authorization information value MUST NOT match any 410 set authorization information value. 411 3. A non-empty input authorization information value MUST be hashed 412 and matched against the set authorization information value, 413 which is stored using the same hash algorithm. 415 5. Create, Transfer, and Secure Authorization Information 417 To make the transfer process secure using secure authorization 418 information, as defined in Section 4, the client and server need to 419 implement steps where the authorization information is set only when 420 a transfer is actively in process and ensure that the authorization 421 information is stored securely and transported only over secure 422 channels. The steps in management of the authorization information 423 for transfers include: 425 1. Registrant requests to register the object with the registrar. 426 Registrar sends the create command, with an empty authorization 427 information value, to the registry, as defined in Section 5.1. 429 2. Registrant requests from the losing registrar the authorization 430 information to provide to the gaining registrar. 431 3. Losing registrar generates a secure random authorization 432 information value, sends it to the registry as defined in 433 Section 5.2, and provides it to the registrant. 434 4. Registrant provides the authorization information value to the 435 gaining registrar. 436 5. Gaining registrar optionally verifies the authorization 437 information with the info command to the registry, as defined in 438 Section 5.3. 439 6. Gaining registrar sends the transfer request with the 440 authorization information to the registry, as defined in 441 Section 5.4. 442 7. If the transfer successfully completes, the registry 443 automatically unsets the authorization information; otherwise the 444 losing registrar unsets the authorization information when the 445 TTL expires, as defined in Section 5.2. 447 The following sections outline the practices of the EPP commands and 448 responses between the registrar and the registry that supports secure 449 authorization information for transfer. 451 5.1. Create Command 453 For a create command, the registry MUST allow for the passing of an 454 empty authorization information value and MAY disallow for the 455 passing of a non-empty authorization information value. By having an 456 empty authorization information value on create, the object is 457 initially not in the transfer process. Any EPP object extension that 458 supports setting the authorization information with a 459 "eppcom:pwAuthInfoType" element, can have an empty authorization 460 information value passed. Examples of such extensions are [RFC5731] 461 and [RFC5733]. 463 Example of passing an empty authorization information value in an 464 [RFC5731] domain name create command. 466 C: 467 C: 468 C: 469 C: 470 C: 472 C: example.com 473 C: 474 C: 475 C: 476 C: 477 C: 478 C: ABC-12345 479 C: 480 C: 482 Example of passing an empty authorization information value in an 483 [RFC5733] contact create command. 485 C: 486 C: 487 C: 488 C: 489 C: 491 C: sh8013 492 C: 493 C: John Doe 494 C: 495 C: Dulles 496 C: US 497 C: 498 C: 499 C: jdoe@example.com 500 C: 501 C: 502 C: 503 C: 504 C: 505 C: ABC-12345 506 C: 507 C: 509 5.2. Update Command 511 For an update command, the registry MUST allow for the setting and 512 unsetting of the authorization information. The registrar sets the 513 authorization information by first generating a strong, random 514 authorization information value, based on Section 4.1, and setting it 515 in the registry in the update command. 517 For an update command, the registry MUST allow for the setting and 518 unsetting of the authorization information. The registrar sets the 519 authorization information by first generating a strong, random 520 authorization information value, based on Section 4.1, and setting it 521 in the registry in the update command. The importance of generating 522 strong authorization information values cannot be overstated: secure 523 transfers are very important to the Internet to mitigate damage in 524 the form of theft, fraud, and other abuse. It is critical that 525 registrars only use strong, randomly generated authorization 526 information values. 528 Because of this, registries may validate the randomness of the 529 authorization information based on the length and character set 530 required by the registry. For example, validating an authorization 531 value contains a combination of upper-case, lower-case, and non- 532 alphanumeric characters, in an attempt to assess the strength of the 533 value, and return an EPP error result of 2202 if the check fails. 535 Such checks are, by their nature, heuristic and imperfect, and may 536 identify well-chosen authorization information values as being not 537 sufficiently strong. Registrars, therefore, must be prepared for an 538 error response of 2202, "Invalid authorization information", and 539 respond by generating a new value and trying again, possibly more 540 than once. 542 Often the registrar has the "clientTransferProhibited" status set, so 543 to start the transfer process, the "clientTransferProhibited" status 544 needs to be removed, and the strong, random authorization information 545 value needs to be set. The registrar MUST define a time-to-live 546 (TTL), as defined in Section 4.2, where if the TTL expires the 547 registrar will unset the authorization information. 549 Example of removing the "clientTransferProhibited" status and setting 550 the authorization information in an [RFC5731] domain name update 551 command. 553 C: 554 C: 555 C: 556 C: 557 C: 559 C: example.com 560 C: 561 C: 562 C: 563 C: 564 C: 565 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP 566 C: 567 C: 568 C: 569 C: 570 C: 571 C: ABC-12345-XYZ 572 C: 573 C: 575 When the registrar-defined TTL expires, the sponsoring registrar 576 cancels the transfer process by unsetting the authorization 577 information value and may add back statuses like the 578 "clientTransferProbited" status. Any EPP object extension that 579 supports setting the authorization information with a 580 "eppcom:pwAuthInfoType" element, can have an empty authorization 581 information value passed. Examples of such extensions are [RFC5731] 582 and [RFC5733]. Setting an empty authorization information value 583 unsets the authorization information. [RFC5731] supports an explicit 584 mechanism of unsetting the authorization information, by passing the 585 authorization information value. The registry MUST 586 support unsetting the authorization information by accepting an empty 587 authorization information value and accepting an explicit unset 588 element if it is supported by the object extension. 590 Example of adding the "clientTransferProhibited" status and unsetting 591 the authorization information explicitly in an [RFC5731] domain name 592 update command. 594 C: 595 C: 596 C: 597 C: 598 C: 600 C: example.com 601 C: 602 C: 603 C: 604 C: 605 C: 606 C: 607 C: 608 C: 609 C: 610 C: 611 C: ABC-12345-XYZ 612 C: 613 C: 615 Example of unsetting the authorization information with an empty 616 authorization information value in an [RFC5731] domain name update 617 command. 619 C: 620 C: 621 C: 622 C: 623 C: 625 C: example.com 626 C: 627 C: 628 C: 629 C: 630 C: 631 C: 632 C: 633 C: 634 C: 635 C: 636 C: ABC-12345-XYZ 637 C: 638 C: 639 Example of unsetting the authorization information with an empty 640 authorization information value in an [RFC5733] contact update 641 command. 643 C: 644 C: 645 C: 646 C: 647 C: 649 C: sh8013 650 C: 651 C: 652 C: 653 C: 654 C: 655 C: 656 C: 657 C: ABC-12345-XYZ 658 C: 659 C: 661 5.3. Info Command and Response 663 For an info command, the registry MUST allow for the passing of a 664 non-empty authorization information value for verification. The 665 gaining registrar can pre-verify the authorization information 666 provided by the registrant prior to submitting the transfer request 667 with the use of the info command. The registry compares the hash of 668 the passed authorization information with the hashed authorization 669 information value stored for the object. When the authorization 670 information is not set or the passed authorization information does 671 not match the previously set value, the registry MUST return an EPP 672 error result code of 2202 [RFC5730]. 674 Example of passing a non-empty authorization information value in an 675 [RFC5731] domain name info command to verify the authorization 676 information value. 678 C: 679 C: 680 C: 681 C: 682 C: 684 C: example.com 685 C: 686 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP 687 C: 688 C: 689 C: 690 C: 691 C: ABC-12345 692 C: 693 C: 695 The info response in object extensions, such as [RFC5731] and 696 [RFC5733], MUST NOT include the optional authorization information 697 element with a non-empty authorization value. The authorization 698 information is stored as a hash in the registry, so returning the 699 plain text authorization information is not possible, unless a valid 700 plain text authorization information is passed in the info command. 701 The registry MUST NOT return any indication of whether the 702 authorization information is set or unset to the non-sponsoring 703 registrar by not returning the authorization information element in 704 the response. The registry MAY return an indication to the 705 sponsoring registrar that the authorization information is set by 706 using an empty authorization information value. The registry MAY 707 return an indication to the sponsoring registrar that the 708 authorization information is unset by not returning the authorization 709 information element. 711 Example of returning an empty authorization information value in an 712 [RFC5731] domain name info response to indicate to the sponsoring 713 registrar that the authorization information is set. 715 S: 716 S: 717 S: 718 S: 719 S: Command completed successfully 720 S: 721 S: 722 S: 724 S: example.com 725 S: EXAMPLE1-REP 726 S: 727 S: ClientX 728 S: 729 S: 730 S: 731 S: 732 S: 733 S: 734 S: ABC-12345 735 S: 54322-XYZ 736 S: 737 S: 738 S: 740 5.4. Transfer Request Command 742 For a Transfer Request Command, the registry MUST allow for the 743 passing of a non-empty authorization information value to authorize a 744 transfer. The registry compares the hash of the passed authorization 745 information with the hashed authorization information value stored 746 for the object. When the authorization information is not set or the 747 passed authorization information does not match the previously set 748 value, the registry MUST return an EPP error result code of 2202 749 [RFC5730]. Whether the transfer occurs immediately or is pending is 750 up to server policy. When the transfer occurs immediately, the 751 registry MUST return the EPP success result code of 1000 and when the 752 transfer is pending, the registry MUST return the EPP success result 753 code of 1001. The losing registrar MUST be informed of a successful 754 transfer request using an EPP poll message. 756 Example of passing a non-empty authorization information value in an 757 [RFC5731] domain name transfer request command to authorize the 758 transfer. 760 C: 761 C: 762 C: 763 C: 764 C: 766 C: example1.com 767 C: 768 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP 769 C: 770 C: 771 C: 772 C: 773 C: ABC-12345 774 C: 775 C: 777 Upon successful completion of the transfer, the registry MUST 778 automatically unset the authorization information. If the transfer 779 request is not submitted within the time-to-live (TTL) (Section 4.2) 780 or the transfer is cancelled or rejected, the registrar MUST unset 781 the authorization information as defined in Section 5.2. 783 6. Transition Considerations 785 The goal of the transition considerations to the practice defined in 786 this document, referred to as the Secure Authorization Information 787 Model, is to minimize the impact to the registrars by supporting 788 incremental steps of adoption. The transtion steps are dependent on 789 the starting point of the registry. Registries may have different 790 starting points, since some of the elements of the Secure 791 Authorization Information Model may have already been implemented. 792 The considerations assume a starting point, referred to as the 793 Classic Authorization Information Model, that have the following 794 steps in the management of the authorization information for 795 transfers: 797 1. Registrant requests to register the object with the registrar. 798 Registrar sends the create command, with a non-empty 799 authorization information value, to the registry. The registry 800 stores the authorization information as an encrypted value and 801 requires a non-empty authorization information value for the life 802 of the object. The registrar may store the long-lived 803 authorization information. 804 2. At the time of transfer, Registrant requests from the losing 805 registrar the authorization information to provide to the gaining 806 registrar. 808 3. Losing registrar retrieves the stored authorization information 809 locally or queries the registry for authorization information 810 using the info command, and provides it to the registrant. If 811 the registry is queried, the authorization information is 812 decrypted and the plain text authorization information is 813 returned in the info response to the registrar. 814 4. Registrant provides the authorization information value to the 815 gaining registrar. 816 5. Gaining registrar optionally verifies the authorization 817 information with the info command to the registry, by passing the 818 authorization information in the info command to the registry. 819 6. Gaining registrar sends the transfer request with the 820 authorization information to the registry. The registry will 821 decrypt the stored authorization information to compare to the 822 passed authorization information. 823 7. If the transfer successfully completes, the authorization 824 information is not touched by the registry and may be updated by 825 the gaining registrar using the update command. If the transfer 826 is cancelled or rejected, the losing registrar may reset the 827 authorization information using the update command. 829 The gaps between the Classic Authorization Information Model and the 830 Secure Authorization Information Model include: 832 1. Registry requirement for a non-empty authorization information 833 value on create and for the life of the object versus the 834 authorization information not being set on create and only being 835 set when a transfer is in process. 836 2. Registry not allowing the authorization information to be unset 837 versus supporting the authorization to be unset in the update 838 command. 839 3. Registry storing the authorization information as an encrypted 840 value versus as a hashed value. 841 4. Registry support for returning the authorization information 842 versus not returning the authorization information in the info 843 response. 844 5. Registry not touching the authorization information versus the 845 registry automatically unsetting the authorization information 846 upon a successful transfer. 847 6. Registry may validate a shorter authorization information value 848 using password complexity rules versus validating the randomness 849 of a longer authorization information value that meets the 850 required bits of entropy. 852 The transition can be handled in the three phases defined in the sub- 853 sections Section 6.1, Section 6.2, Section 6.3. 855 6.1. Transition Phase 1 - Features 857 The goal of the "Transition Phase 1 - Features" is to implement the 858 needed features in EPP so that the registrar can optionally implement 859 the Secure Authorization Information Model. The features to 860 implement are broken out by the command and responses below: 862 Create Command: Change the create command to make the authorization 863 information optional, by allowing both a non-empty value and an 864 empty value. This enables a registrar to optionally create 865 objects without an authorization information value, as defined in 866 Section 5.1. 867 Update Command: Change the update command to allow unsetting the 868 authorization information, as defined in Section 5.2. This 869 enables the registrar to optionally unset the authorization 870 information when the TTL expires or when the transfer is cancelled 871 or rejected. 872 Transfer Approve Command and Transfer Auto-Approve: Change the 873 transfer approve command and the transfer auto-approve to 874 automatically unset the authorization information. This sets the 875 default state of the object to not have the authorization 876 information set. The registrar implementing the Secure 877 Authorization Information Model will not set the authorization 878 information for an inbound transfer and the registrar implementing 879 the Classic Authorization Information Model will set the new 880 authorization information upon the successful transfer. 881 Info Response: Change the info command to not return the 882 authorization information in the info response, as defined in 883 Section 5.3. This sets up the implementation of "Transition Phase 884 2 - Storage", since the dependency in returning the authorization 885 information in the info response will be removed. This feature is 886 the only one that is not an optional change to the registrar. 887 Info Command and Transfer Request: Change the info command and the 888 transfer request to ensure that a registrar cannot get an 889 indication that the authorization information is set or not set by 890 returning the EPP error result code of 2202 when comparing a 891 passed authorization to a non-matching set authorization 892 information value or an unset value. 894 6.2. Transition Phase 2 - Storage 896 The goal of the "Transition Phase 2 - Storage" is to transition the 897 registry to use hashed authorization information instead of encrypted 898 authorization information. There is no direct impact to the 899 registrars, since the only visible indication that the authorization 900 information has been hashed is by not returning the set authorization 901 information in the info response, which is addressed in Transition 902 Phase 1 - Features (Section 6.1). There are three steps to 903 transition the authorization information storage, which includes: 905 Hash New Authorization Information Values: Change the create command 906 and the update command to hash instead of encyrpting the 907 authorization information. 908 Supporting Comparing Against Encrypted and Hashed Authorization 909 Information: Change the info command and the transfer request 910 command to be able to compare a passed authorization information 911 value with either a hashed or encyrpted authorization information 912 value. 913 Hash Existing Encrypted Authorization Information Values: Convert 914 the encrypted authorization information values stored in the 915 registry database to hashed values. The update is not a visible 916 change to the registrar. The conversion can be done over a period 917 of time depending on registry policy. 919 6.3. Transition Phase 3 - Enforcement 921 The goal of the "Transition Phase 3 - Enforcement" is to complete the 922 implementation of the "Secure Authorization Information Model", by 923 enforcing the following: 925 Disallow Authorization Information on Create Command: Change the 926 create command to not allow for the passing of a non-empty 927 authorization information value. 928 Validate the Strong Random Authorization Information: Change the 929 validation of the authorization information in the update command 930 to ensure at least 128 bits of entropy. 932 7. IANA Considerations 934 7.1. XML Namespace 936 This document uses URNs to describe XML namespaces conforming to a 937 registry mechanism described in [RFC3688]. The following URI 938 assignment is requested of IANA: 940 Registration request for the secure authorization information for 941 transfer namespace: 943 URI: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0 944 Registrant Contact: IESG 945 XML: None. Namespace URIs do not represent an XML specification. 947 7.2. EPP Extension Registry 949 The EPP operational practice described in this document should be 950 registered by the IANA in the EPP Extension Registry described in 951 [RFC7451]. The details of the registration are as follows: 953 Name of Extension: "Extensible Provisioning Protocol (EPP) Secure 954 Authorization Information for Transfer" 956 Document status: Standards Track 958 Reference: (insert reference to RFC version of this document) 960 Registrant Name and Email Address: IESG, 962 TLDs: Any 964 IPR Disclosure: None 966 Status: Active 968 Notes: None 970 8. Implementation Status 972 Note to RFC Editor: Please remove this section and the reference to 973 RFC 7942 [RFC7942] before publication. 975 This section records the status of known implementations of the 976 protocol defined by this specification at the time of posting of this 977 Internet-Draft, and is based on a proposal described in RFC 7942 978 [RFC7942]. The description of implementations in this section is 979 intended to assist the IETF in its decision processes in progressing 980 drafts to RFCs. Please note that the listing of any individual 981 implementation here does not imply endorsement by the IETF. 982 Furthermore, no effort has been spent to verify the information 983 presented here that was supplied by IETF contributors. This is not 984 intended as, and must not be construed to be, a catalog of available 985 implementations or their features. Readers are advised to note that 986 other implementations may exist. 988 According to RFC 7942 [RFC7942], "this will allow reviewers and 989 working groups to assign due consideration to documents that have the 990 benefit of running code, which may serve as evidence of valuable 991 experimentation and feedback that have made the implemented protocols 992 more mature. It is up to the individual working groups to use this 993 information as they see fit". 995 8.1. Verisign EPP SDK 997 Organization: Verisign Inc. 999 Name: Verisign EPP SDK 1001 Description: The Verisign EPP SDK includes both a full client 1002 implementation and a full server stub implementation of draft-ietf- 1003 regext-secure-authinfo-transfer. 1005 Level of maturity: Development 1007 Coverage: All aspects of the protocol are implemented. 1009 Licensing: GNU Lesser General Public License 1011 Contact: jgould@verisign.com 1013 URL: https://www.verisign.com/en_US/channel-resources/domain- 1014 registry-products/epp-sdks 1016 8.2. RegistryEngine EPP Service 1018 Organization: CentralNic 1020 Name: RegistryEngine EPP Service 1022 Description: Generic high-volume EPP service for gTLDs, ccTLDs and 1023 SLDs 1025 Level of maturity: Deployed in CentralNic's production environment as 1026 well as two other gTLD registry systems, and two ccTLD registry 1027 systems. 1029 Coverage: Authorization Information is "write only" in that the 1030 registrars can set the Authorization Information, but not get the 1031 Authorization Information in the Info Response. 1033 Licensing: Proprietary In-House software 1035 Contact: epp@centralnic.com 1037 URL: https://www.centralnic.com 1039 9. Security Considerations 1041 Section 4.1 defines the use a secure random value for the generation 1042 of the authorization information. The server SHOULD define policy 1043 related to the length and set of characters that are included in the 1044 randomization to target the desired entropy level, with the 1045 recommendation of at least 128 bits for entropy. The authorization 1046 information server policy is communicated to the client using an out- 1047 of-band process. The client SHOULD choose a length and set of 1048 characters that results in entropy that meets or exceeds the server 1049 policy. A random number generator (RNG) is preferable over the use 1050 of a pseudorandom number generator (PRNG) when creating the 1051 authorization information value. 1053 Section 4.2 defines the use of an authorization information Time-To- 1054 Live (TTL). The registrar SHOULD only set the authorization 1055 information during the transfer process by the server support for 1056 setting and unsetting the authorization information. The TTL value 1057 is up to registrar policy and the sponsoring registrar MUST inform 1058 the registrant of the TTL when providing the authorization 1059 information to the registrant. 1061 Section 4.3 defines the storage and transport of authorization 1062 information. The losing registrar MUST NOT store the authorization 1063 information and the gaining registrar MUST only store the 1064 authorization information as a "transient" value during the transfer 1065 process, where the authorization information MUST NOT be stored after 1066 the end of the transfer process. The registry MUST store the 1067 authorization information using a one-way cryptographic hash of at 1068 least 256 bits and with a random salt. All communication that 1069 includes the authorization information MUST be over an encrypted 1070 channel. The plain text authorization information MUST NOT be 1071 written to any logs by the registrar or the registry. 1073 Section 4.4 defines the matching of the authorization information 1074 values. The registry stores an unset authorization information as a 1075 NULL (undefined) value to ensure that an empty input authorization 1076 information never matches it. The method used to define a NULL 1077 (undefined) value is database specific. 1079 10. Acknowledgements 1081 The authors wish to thank the following persons for their feedback 1082 and suggestions: Michael Bauland, Martin Casanova, Scott Hollenbeck, 1083 Jody Kolker, Barry Leiba, Patrick Mevzek, Matthew Pozun, Srikanth 1084 Veeramachaneni, and Ulrich Wisser. 1086 11. References 1087 11.1. Normative References 1089 [FIPS-140-2] 1090 National Institute of Standards and Technology, U.S. 1091 Department of Commerce, "NIST Federal Information 1092 Processing Standards (FIPS) Publication 140-2", May 2001, 1093 . 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-180-4] 1144 National Institute of Standards and Technology, U.S. 1145 Department of Commerce, "Secure Hash Standard, NIST 1146 Federal Information Processing Standards (FIPS) 1147 Publication 180-4", August 2015, 1148 . 1151 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1152 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1153 February 2015, . 1155 Appendix A. Change History 1157 A.1. Change from 00 to 01 1159 1. Filled in the "Implementation Status" section with the inclusion 1160 of the "Verisign EPP SDK" and "RegistryEngine EPP Service" 1161 implementations. 1162 2. Made small wording corrections based on private feedback. 1163 3. Added content to the "Acknowledgements" section. 1165 A.2. Change from 01 to 02 1167 1. Revised the language used for the storage of the authorization 1168 information based on the feedback from Patrick Mevzek and Jody 1169 Kolker. 1171 A.3. Change from 02 to 03 1173 1. Updates based on the feedback from the interim REGEXT meeting 1174 held at ICANN-66: 1175 1. Section 3.3, include a reference to the hash algorithm to 1176 use. Broke the requirements into a list and included a the 1177 reference the text ', with at least a 256-bit hash function, 1178 such as SHA-256'. 1180 2. Add a Transition Considerations section to cover the 1181 transition from the classic authorization information 1182 security model in the EPP RFCs to the model defined in the 1183 document. 1184 3. Add a statement to the Introduction that elements of the 1185 practice can be used for purposes other than transfer, but 1186 with a caveat. 1187 2. Updates based on the review by Michael Bauland, that include: 1188 1. In section 2, change 'there are three actors' to 'there are 1189 three types of actors' to cover the case with transfers that 1190 has two registrar actors (losing and gaining). 1191 2. In section 3.1, change the equations equals to be 1192 approximately equal by using '=~' instead of '=', where 1193 applicable. 1194 3. In section 3.3, change 'MUST be over an encrypted channel, 1195 such as RFC5734' to 'MUST be over an encrypted channel, such 1196 as defined in RFC5734'. 1197 4. In section 4.1, remove the optional RFC 5733 elements from 1198 the contact create, which includes the , 1199 , , , 1200 , , and elements. 1201 5. In section 4.2, changed 'Example of unsetting the 1202 authorization information explicitly in an [RFC5731] domain 1203 name update command.' to 'Example of adding the 1204 "clientTransferProhibited" status and unsetting the 1205 authorization information explicitly in an [RFC5731] domain 1206 name update command.' 1207 6. In section 4.3, cover a corner case of the ability to return 1208 the authorization information when it's passed in the info 1209 command. 1210 7. In section 4.4, change 'If the transfer does not complete 1211 within the time-to-live (TTL)' to 'If the transfer is not 1212 initiated within the time-to-live (TTL)', since the TTL is 1213 the time between setting the authorization information and 1214 when it's successfully used in a transfer request. Added the 1215 case of unsetting the authorization information when the 1216 transfer is cancelled or rejected. 1217 3. Updates based on the authorization information messages by Martin 1218 Casanova on the REGEXT mailing list, that include: 1219 1. Added section 3.4 'Authorization Information Matching' to 1220 clarify how the authorization information is matched, when 1221 there is set and unset authorization information in the 1222 database and empty and non-empty authorization information 1223 passed in the info and transfer commands. 1224 2. Added support for signaling that the authorization 1225 information is set or unset to the sponsoring registrar with 1226 the inclusion of an empty authorization information element 1227 in the response to indicate that the authorization 1228 information is set and the exclusion of the authorization 1229 information element in the response to indicate that the 1230 authorization information is unset. 1231 4. Made the capitalization of command and response references 1232 consistent by uppercasing section and item titles and lowercasing 1233 references elsewhere. 1235 A.4. Change from 03 to REGEXT 00 1237 1. Changed to regext working group draft by changing draft-gould- 1238 regext-secure-authinfo-transfer to draft-ietf-regext-secure- 1239 authinfo-transfer. 1241 A.5. Change from REGEXT 00 to REGEXT 01 1243 1. Added the "Signaling Client and Server Support" section to 1244 describe the mechanism to signal support for the BCP by the 1245 client and the server. 1246 2. Added the "IANA Considerations" section with the registration of 1247 the secure authorization for transfer XML namespace and the 1248 registration of the EPP Best Current Practice (BCP) in the EPP 1249 Extension Registry. 1251 A.6. Change from REGEXT 01 to REGEXT 02 1253 1. Added inclusion of random salt for the hashed authorization 1254 information, based on feedback from Ulrich Wisser. 1255 2. Added clarification that the representation of a NULL (undefined) 1256 value is dependent on the type of database, based on feedback 1257 from Patrick Mevzek. 1258 3. Filled in the Security Considerations section. 1260 A.7. Change from REGEXT 02 to REGEXT 03 1262 1. Updated the XML namespace to urn:ietf:params:xml:ns:epp:secure- 1263 authinfo-transfer-1.0, which removed bcp from the namespace and 1264 bumped the version from 0.1 and 1.0. Inclusion of bcp in the XML 1265 namespace was discussed at the REGEXT interim meeting. 1266 2. Replaced Auhtorization with Authorization based on a review by 1267 Jody Kolker. 1269 A.8. Change from REGEXT 03 to REGEXT 04 1271 1. Converted from xml2rfc v2 to v3. 1272 2. Updated Acknowledgements to match the approach taken by the RFC 1273 Editor with draft-ietf-regext-login-security. 1274 3. Changed from Best Current Practice (BCP) to Standards Track based 1275 on mailing list discussion. 1277 A.9. Change from REGEXT 04 to REGEXT 05 1279 1. Fixed IDNITS issues, including moving RFC7451 to Informative 1280 References section. 1282 A.10. Change from REGEXT 05 to REGEXT 06 1284 Updates based on the Barry Leiba (AD) feedback: 1286 1. Simplified the abstract based on the proposal provided. 1287 2. In the Introduction, split the first paragraph by starting a new 1288 paragraph at "This document". 1289 3. In section 1.1, updated to use the new BCP 14 boilerplate and 1290 add a normative reference to RFC 8174. 1291 4. In section 4, Updated the phrasing to "For the authorization 1292 information to be secure it must be generated using a strong 1293 random value and have a short time-to-live (TTL).". 1294 5. In section 4.1, removed the first two unnecessary calculations 1295 and condensed the introduction of the section. 1296 6. In section 4.1, added the use of the normative SHOULD for use of 1297 at least 128 bits of entropy. 1298 7. Added an informative reference to FIPS 180-4 for the SHA-256 1299 references. 1300 8. Normalized the way that the "empty and non-empty authorization 1301 information values" are referenced, which a few exceptions. 1302 9. In section 4, revised the first sentence to explicitly reference 1303 the use of the and elements for 1304 password-based authorization information. 1305 10. In section 4.4, revised the language associated with the storage 1306 of the authorization information to be cleaner. 1307 11. In section 4.4, added "set" in the sentence "An empty input 1308 authorization information value MUST NOT match any set 1309 authorization information value." 1310 12. In section 5.1 and 5.2, clarified the references to RFC5731 and 1311 RFC5733 as examples of object extensions that use the 1312 "eppcom:pwAuthInfoType" element. 1313 13. In section 5.2, updated language for the validation of the 1314 randomness of the authorization information, based on an offline 1315 review by Barrry Leiba, Benjamin Kaduk, and Roman Danyliw. 1316 14. In section 9, changed "49 bits of entropy" to "128 bits of 1317 entropy". 1319 In section 3, replaced the reference to BCP with operational 1320 practice, since the draft is not defined as a BCP. 1322 Authors' Addresses 1323 James Gould 1324 VeriSign, Inc. 1325 12061 Bluemont Way 1326 Reston, VA 20190 1327 United States of America 1329 Email: jgould@verisign.com 1330 URI: http://www.verisign.com 1332 Richard Wilhelm 1333 VeriSign, Inc. 1334 12061 Bluemont Way 1335 Reston, VA 20190 1336 United States of America 1338 Email: rwilhelm@verisign.com 1339 URI: http://www.verisign.com