idnits 2.17.1 draft-ietf-regext-secure-authinfo-transfer-03.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 (July 31, 2020) is 1365 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 1131 ** Downref: Normative reference to an Informational RFC: RFC 7451 ** Obsolete normative reference: RFC 8499 (Obsoleted by RFC 9499) Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gould 3 Internet-Draft R. Wilhelm 4 Intended status: Best Current Practice VeriSign, Inc. 5 Expires: February 1, 2021 July 31, 2020 7 Extensible Provisioning Protocol (EPP) Secure Authorization Information 8 for Transfer 9 draft-ietf-regext-secure-authinfo-transfer-03 11 Abstract 13 The Extensible Provisioning Protocol (EPP), in RFC 5730, defines the 14 use of authorization information to authorize a transfer. The 15 authorization information is object-specific and has been defined in 16 the EPP Domain Name Mapping, in RFC 5731, and the EPP Contact 17 Mapping, in RFC 5733, as password-based authorization information. 18 Other authorization mechanisms can be used, but in practice the 19 password-based authorization information has been used at the time of 20 object create, managed with the object update, and used to authorize 21 an object transfer request. What has not been fully considered is 22 the security of the authorization information that includes the 23 complexity of the authorization information, the time-to-live (TTL) 24 of the authorization information, and where and how the authorization 25 information is stored. This document defines an operational 26 practice, using the EPP RFCs, that leverages the use of strong random 27 authorization information values that are short-lived, that are not 28 stored by the client, and that are stored using a cryptographic hash 29 by the server to provide for secure authorization information used 30 for transfers. 32 Status of This Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at https://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on February 1, 2021. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 68 2. Registrant, Registrar, Registry . . . . . . . . . . . . . . . 5 69 3. Signaling Client and Server Support . . . . . . . . . . . . . 6 70 4. Secure Authorization Information . . . . . . . . . . . . . . 7 71 4.1. Secure Random Authorization Information . . . . . . . . . 7 72 4.2. Authorization Information Time-To-Live (TTL) . . . . . . 8 73 4.3. Authorization Information Storage and Transport . . . . . 8 74 4.4. Authorization Information Matching . . . . . . . . . . . 9 75 5. Create, Transfer, and Secure Authorization Information . . . 9 76 5.1. Create Command . . . . . . . . . . . . . . . . . . . . . 10 77 5.2. Update Command . . . . . . . . . . . . . . . . . . . . . 12 78 5.3. Info Command and Response . . . . . . . . . . . . . . . . 15 79 5.4. Transfer Request Command . . . . . . . . . . . . . . . . 16 80 6. Transition Considerations . . . . . . . . . . . . . . . . . . 17 81 6.1. Transition Phase 1 - Features . . . . . . . . . . . . . . 19 82 6.2. Transition Phase 2 - Storage . . . . . . . . . . . . . . 19 83 6.3. Transition Phase 3 - Enforcement . . . . . . . . . . . . 20 84 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 85 7.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 20 86 7.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 21 87 8. Implementation Status . . . . . . . . . . . . . . . . . . . . 21 88 8.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 22 89 8.2. RegistryEngine EPP Service . . . . . . . . . . . . . . . 22 90 9. Security Considerations . . . . . . . . . . . . . . . . . . . 23 91 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 92 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 24 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 24 94 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 25 95 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 25 96 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 25 97 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 25 98 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 25 99 A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 27 100 A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 27 101 A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 27 102 A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 27 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 105 1. Introduction 107 The Extensible Provisioning Protocol (EPP), in [RFC5730], defines the 108 use of authorization information to authorize a transfer. The 109 authorization information is object-specific and has been defined in 110 the EPP Domain Name Mapping, in [RFC5731], and the EPP Contact 111 Mapping, in [RFC5733], as password-based authorization information. 112 Other authorization mechanisms can be used, but in practice the 113 password-based authorization information has been used at the time of 114 object create, managed with the object update, and used to authorize 115 an object transfer request. What has not been considered is the 116 security of the authorization information that includes the 117 complexity of the authorization information, the time-to-live (TTL) 118 of the authorization information, and where and how the authorization 119 information is stored. This document defines an operational 120 practice, using the EPP RFCs, that leverages the use of strong, 121 random authorization information values that are short-lived, that 122 are not stored by the client, and that are stored by the server using 123 a cryptographic hash to provide, for secure authorization information 124 used for transfers. This operational practice can be used to support 125 transfers of any EPP object, where the domain name object defined in 126 [RFC5731] is used in this document for illustration purposes. 127 Elements of the practice may be used to support the secure use of the 128 authorization information for purposes other than transfer, but any 129 other purposes and the applicable elements are out-of-scope for this 130 document. 132 The overall goal is to have strong, random authorization information 133 values, that are short-lived, and that are either not stored or 134 stored as a cryptographic hash values by the non-responsible parties. 135 In a registrant, registrar, and registry model, the registrant 136 registers the object through the registrar to the registry. The 137 registrant is the responsible party and the registrar and the 138 registry are the non-responsible parties. EPP is a protocol between 139 the registrar and the registry, where the registrar is referred to as 140 the client and the registry is referred to as the server. The 141 following are the elements of the operational practice and how the 142 existing features of the EPP RFCs can be leveraged to satisfy them: 144 "Strong Random Authorization Information": The EPP RFCs define the 145 password-based authorization information value using an XML 146 schema "normalizedString" type, so they don't restrict what can 147 be used in any way. This operational practice defines the 148 recommended mechanism for creating a strong random authorization 149 value, that would be generated by the client. 150 "Short-Lived Authorization Information": The EPP RFCs don't 151 explicitly support short-lived authorization information or a 152 time-to-live (TTL) for authorization information, but there are 153 EPP RFC features that can be leveraged to support short-lived 154 authorization information. If authorization information is set 155 only when there is a transfer in process, the server needs to 156 support empty authorization information on create, support 157 setting and unsetting authorization information, and support 158 automatically unsetting the authorization information upon a 159 successful transfer. All of these features can be supported by 160 the EPP RFCs. 161 "Storing Authorization Information Securely": The EPP RFCs don't 162 specify where and how the authorization information is stored in 163 the client or the server, so there are no restrictions to define 164 an operational practice for storing the authorization information 165 securely. The operational practice will not require the client 166 to store the authorization information and will require the 167 server to store the authorization information using a 168 cryptographic hash, with at least a 256-bit hash function such as 169 SHA-256, and with a random salt. Returning the authorization 170 information set in an EPP info response will not be supported. 172 1.1. Conventions Used in This Document 174 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 175 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 176 document are to be interpreted as described in RFC 2119 [RFC2119]. 178 XML is case sensitive. Unless stated otherwise, XML specifications 179 and examples provided in this document MUST be interpreted in the 180 character case presented in order to develop a conforming 181 implementation. 183 In examples, "C:" represents lines sent by a protocol client and "S:" 184 represents lines returned by a protocol server. Indentation and 185 white space in examples are provided only to illustrate element 186 relationships and are not a required feature of this protocol. 188 The examples reference XML namespace prefixes that are used for the 189 associated XML namespaces. Implementations MUST NOT depend on the 190 example XML namespaces and instead employ a proper namespace-aware 191 XML parser and serializer to interpret and output the XML documents. 193 The example namespace prefixes used and their associated XML 194 namespaces include: 196 "domain": urn:ietf:params:xml:ns:domain-1.0 197 "contact": urn:ietf:params:xml:ns:contact-1.0 199 2. Registrant, Registrar, Registry 201 The EPP RFCs refer to client and server, but when it comes to 202 transfers, there are three types of actors that are involved. This 203 document will refer to the actors as registrant, registrar, and 204 registry. [RFC8499] defines these terms formally for the Domain Name 205 System (DNS). The terms are further described below to cover their 206 roles as actors of using the authorization information in the 207 transfer process of any object in the registry, such as a domain name 208 or a contact: 210 "registrant": [RFC8499] defines the registrant as "an individual or 211 organization on whose behalf a name in a zone is registered by 212 the registry". The registrant can be the owner of any object in 213 the registry, such as a domain name or a contact. The registrant 214 interfaces with the registrar for provisioning the objects. A 215 transfer is coordinated by the registrant to transfer the 216 sponsorship of the object from one registrar to another. The 217 authorization information is meant to authenticate the registrant 218 as the owner of the object to the non-sponsoring registrar and to 219 authorize the transfer. 220 "registrar": [RFC8499] defines the registrar as "a service provider 221 that acts as a go-between for registrants and registries". The 222 registrar interfaces with the registrant for the provisioning of 223 objects, such as domain names and contacts, and with the 224 registries to satisfy the registrant's provisioning requests. A 225 registrar may directly interface with the registrant or may 226 indirectly interface with the registrant, typically through one 227 or more resellers. Implementing a transfer using secure 228 authorization information extends through the registrar's 229 reseller channel up to the direct interface with the registrant. 230 The registrar's interface with the registries uses EPP. The 231 registrar's interface with its reseller channel or the registrant 232 is registrar-specific. In the EPP RFCs, the registrar is 233 referred to as the "client", since EPP is the protocol used 234 between the registrar and the registry. The sponsoring registrar 235 is the authorized registrar to manage objects on behalf of the 236 registrant. A non-sponsoring registrar is not authorized to 237 manage objects on behalf of the registrant. A transfer of an 238 object's sponsorship is from one registrar, referred to as the 239 losing registrar, to another registrar, referred to as the 240 gaining registrar. 242 "registry": [RFC8499] defines the registry as "the administrative 243 operation of a zone that allows registration of names within the 244 zone". The registry typically interfaces with the registrars 245 over EPP and generally does not interact directly with the 246 registrant. In the EPP RFCs, the registry is referred to as the 247 "server", since EPP is the protocol used between the registrar 248 and the registry. The registry has a record of the sponsoring 249 registrar for each object and provides the mechanism (over EPP) 250 to coordinate a transfer of an object's sponsorship between 251 registrars. 253 3. Signaling Client and Server Support 255 This document does not define new protocol but a Best Current 256 Practice (BCP) using the existing EPP protocol, where the client and 257 the server can signal support for the BCP using a namespace URI in 258 the login and greeting extension services. The namespace URI 259 "urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0" is used to 260 signal support for the BCP. The client includes the namespace URI in 261 an element of the [RFC5730] Command. 262 The server includes the namespace URI in an 263 element of the [RFC5730] Greeting. 265 A client that receives the namespace URI in the server's Greeting 266 extension services, can expect the following supported behavior by 267 the server: 269 1. Support empty authorization information with a create command. 270 2. Support unsetting authorization information with an update 271 command. 272 3. Support validating authorization information with an info 273 command. 274 4. Support not returning an indication whether the authorization 275 information is set or unset to the non-sponsoring registrar. 276 5. Support returning empty authorization information to sponsoring 277 registrar when the authorization information is set in an info 278 response. 279 6. Support allowing for the passing of a matching non-empty 280 authorization information to authorize a transfer. 281 7. Support automatically unsetting the authorization information 282 upon a successful completion of transfer. 284 A server that receives the namespace URI in the client's 285 Command extension services, can expect the following supported 286 behavior by the client: 288 1. Support generation of authorization information using a secure 289 random value. 291 2. Support only setting the authorization information when there is 292 a transfer in process. 294 4. Secure Authorization Information 296 The authorization information in the EPP RFCs ([RFC5731] and 297 [RFC5733]) that support transfer use password-based authorization 298 information. Other EPP objects that support password-based 299 authorization information for transfer can use the Secure 300 Authorization Information defined in this document. For the 301 authorization information to be secure it must be a strong random 302 value and must have a short time-to-live (TTL). The security of the 303 authorization information is defined in the following 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). With a target entropy of 314 49, the required length can be calculated after deciding on the set 315 of characters that will be randomized. The following are a set of 316 possible character sets and the calculation of the required length. 318 Calculation of the required length with 49 bits of entropy and with 319 the set of all printable ASCII characters except space (0x20), which 320 consists of the 94 characters 0x21-0x7E. 322 ROUNDUP(49 / log2 94) =~ ROUNDUP(49 / 6.55) =~ ROUNDUP(7.48) = 8 324 Calculation of the required length with 49 bits of entropy and with 325 the set of case-insensitive alphanumeric characters, which consists 326 of 36 characters (a-z A-Z 0-9). 328 ROUNDUP(49 / log2 36) =~ ROUNDUP(49 / 5.17) =~ ROUNDUP(9.48) = 10 330 Considering the age of [RFC4086], the evolution of security 331 practices, and that the authorization information is a machine- 332 generated value, the recommendation is to use at least 128 bits of 333 entropy. The lengths are recalculated below using 128 bits of 334 entropy. 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 actual entropy of the underlying random number generator. For 350 the random number generator, the practices defined in [RFC4086] and 351 section 4.7.1 of the NIST Federal Information Processing Standards 352 (FIPS) Publication 140-2 [1] SHOULD be followed to produce random 353 values that will be resistant to attack. A random number generator 354 (RNG) is preferable over the use of a pseudorandom number generator 355 (PRNG) to reduce the predictability of the authorization information. 356 The more predictable the random number generator is, the lower the 357 true entropy, and the longer the required length for the 358 authorization information. 360 4.2. Authorization Information Time-To-Live (TTL) 362 The authorization information SHOULD only be set when there is a 363 transfer in process. This implies that the authorization information 364 has a Time-To-Live (TTL) by which the authorization information is 365 cleared when the TTL expires. The EPP RFCs have no definition of 366 TTL, but since the server supports the setting and unsetting of the 367 authorization information by the sponsoring registrar, then the 368 sponsoring registrar can apply a TTL based on client policy. The TTL 369 client policy may be based on proprietary registrar-specific criteria 370 which provides for a transfer-specific TTL tuned for the particular 371 circumstances of the transaction. The sponsoring registrar will be 372 aware of the TTL and the sponsoring registrar MUST inform the 373 registrant of the TTL when the authorization information is provided 374 to the registrant. 376 4.3. Authorization Information Storage and Transport 378 To protect the disclosure of the authorization information, the 379 following requirements apply: 381 1. The authorization information MUST be stored by the registry 382 using a strong one-way cryptographic hash, with at least a 383 256-bit hash function such as SHA-256, and with a random salt. 385 2. An empty authorization information MUST be stored as an undefined 386 value that is referred to as a NULL value. The representation of 387 an 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 the registrar or the registry. 396 6. All communication that includes the authorization information 397 MUST be over an encrypted channel, such as defined in [RFC5734] 398 for EPP. 399 7. The registrar's interface for communicating the authorization 400 information with the registrant MUST be over an authenticated and 401 encrypted channel. 403 4.4. Authorization Information Matching 405 To support the authorization information TTL, as defined in 406 Section 4.2, the authorization information must have either a set or 407 unset state. The unset authorization information is stored with a 408 NULL (undefined) value. Based on the requirement to store the 409 authorization information using a strong one-way cryptographic hash, 410 as defined in Section 4.3, a set authorization information is stored 411 with a non-NULL hashed value. The empty authorization information is 412 used as input in both the create command (Section 5.1) and the update 413 command (Section 5.2) to define the unset state. The matching of the 414 authorization information in the info command (Section 5.3) and the 415 transfer request command (Section 5.4) is based on the following 416 rules: 418 1. Any input authorization information value MUST NOT match an unset 419 authorization information value. 420 2. An empty input authorization information value MUST NOT match any 421 authorization information value. 422 3. A non-empty input authorization information value MUST be hashed 423 and matched against the set authorization information value, 424 which is stored using the same hash algorithm. 426 5. Create, Transfer, and Secure Authorization Information 428 To make the transfer process secure using secure authorization 429 information, as defined in Section 4, the client and server need to 430 implement steps where the authorization information is set only when 431 a transfer is actively in process and ensure that the authorization 432 information is stored securely and transported only over secure 433 channels. The steps in management of the authorization information 434 for transfers include: 436 1. Registrant requests to register the object with the registrar. 437 Registrar sends the create command, with empty authorization 438 information, to the registry, as defined in Section 5.1. 439 2. Registrant requests from the losing registrar the authorization 440 information to provide to the gaining registrar. 441 3. Losing registrar generates a secure random authorization 442 information value, sends it to the registry as defined in 443 Section 5.2, and provides it to the registrant. 444 4. Registrant provides the authorization information value to the 445 gaining registrar. 446 5. Gaining registrar optionally verifies the authorization 447 information with the info command to the registry, as defined in 448 Section 5.3. 449 6. Gaining registrar sends the transfer request with the 450 authorization information to the registry, as defined in 451 Section 5.4. 452 7. If the transfer successfully completes, the registry 453 automatically unsets the authorization information; otherwise the 454 losing registrar unsets the authorization information when the 455 TTL expires, as defined in Section 5.2. 457 The following sections outline the practices of the EPP commands and 458 responses between the registrar and the registry that supports secure 459 authorization information for transfer. 461 5.1. Create Command 463 For a create command, the registry MUST allow for the passing of an 464 empty authorization information and MAY disallow for the passing of a 465 non-empty authorization information. By having an empty 466 authorization information on create, the object is initially not in 467 the transfer process. Any EPP object extension that supports setting 468 the authorization information with a "eppcom:pwAuthInfoType" element, 469 can have an empty authorization information passed, such as [RFC5731] 470 and [RFC5733]. 472 Example of passing empty authorization information in an [RFC5731] 473 domain name create command. 475 C: 476 C: 477 C: 478 C: 479 C: 481 C: example.com 482 C: 483 C: 484 C: 485 C: 486 C: 487 C: ABC-12345 488 C: 489 C: 491 Example of passing empty authorization information in an [RFC5733] 492 contact create command. 494 C: 495 C: 496 C: 497 C: 498 C: 500 C: sh8013 501 C: 502 C: John Doe 503 C: 504 C: Dulles 505 C: US 506 C: 507 C: 508 C: jdoe@example.com 509 C: 510 C: 511 C: 512 C: 513 C: 514 C: ABC-12345 515 C: 516 C: 518 5.2. Update Command 520 For an update command, the registry MUST allow for the setting and 521 unsetting of the authorization information. The registrar sets the 522 authorization information by first generating a strong, random 523 authorization information value, based on Section 4.1, and setting it 524 in the registry in the update command. The registry SHOULD validate 525 the randomness of the authorization information based on the length 526 and character set required by the registry. For example, a registry 527 that requires 20 random printable ASCII characters except space 528 (0x20), should validate that the authorization information contains 529 at least one upper case alpha character, one lower case alpha 530 character, and one non-alpha numeric character. If the authorization 531 information fails the randomness validation, the registry MUST return 532 an EPP error result code of 2202. 534 Often the registrar has the "clientTransferProhibited" status set, so 535 to start the transfer process, the "clientTransferProhibited" status 536 needs to be removed, and the strong, random authorization information 537 value needs to be set. The registrar MUST define a time-to-live 538 (TTL), as defined in Section 4.2, where if the TTL expires the 539 registrar will unset the authorization information. 541 Example of removing the "clientTransferProhibited" status and setting 542 the authorization information in an [RFC5731] domain name update 543 command. 545 C: 546 C: 547 C: 548 C: 549 C: 551 C: example.com 552 C: 553 C: 554 C: 555 C: 556 C: 557 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP 558 C: 559 C: 560 C: 561 C: 562 C: 563 C: ABC-12345-XYZ 564 C: 565 C: 566 When the registrar-defined TTL expires, the sponsoring registrar 567 cancels the transfer process by unsetting the authorization 568 information value and may add back statuses like the 569 "clientTransferProbited" status. Any EPP object extension that 570 supports setting the authorization information with a 571 "eppcom:pwAuthInfoType" element, can have an empty authorization 572 information passed, such as [RFC5731] and [RFC5733]. Setting an 573 empty authorization information unsets the value. [RFC5731] supports 574 an explicit mechanism of unsetting the authorization information, by 575 passing the authorization information value. The 576 registry MUST support unsetting the authorization information by 577 accepting an empty authorization information value and accepting an 578 explicit unset element if it is supported by the object extension. 580 Example of adding the "clientTransferProhibited" status and unsetting 581 the authorization information explicitly in an [RFC5731] domain name 582 update command. 584 C: 585 C: 586 C: 587 C: 588 C: 590 C: example.com 591 C: 592 C: 593 C: 594 C: 595 C: 596 C: 597 C: 598 C: 599 C: 600 C: 601 C: ABC-12345-XYZ 602 C: 603 C: 604 Example of unsetting the authorization information with an empty 605 authorization information in an [RFC5731] domain name update command. 607 C: 608 C: 609 C: 610 C: 611 C: 613 C: example.com 614 C: 615 C: 616 C: 617 C: 618 C: 619 C: 620 C: 621 C: 622 C: 623 C: 624 C: ABC-12345-XYZ 625 C: 626 C: 628 Example of unsetting the authorization information with an empty 629 authorization information in an [RFC5733] contact update command. 631 C: 632 C: 633 C: 634 C: 635 C: 637 C: sh8013 638 C: 639 C: 640 C: 641 C: 642 C: 643 C: 644 C: 645 C: ABC-12345-XYZ 646 C: 647 C: 649 5.3. Info Command and Response 651 For an info command, the registry MUST allow for the passing of a 652 non-empty authorization information for verification. The gaining 653 registrar can pre-verify the authorization information provided by 654 the registrant prior to submitting the transfer request with the use 655 of the info command. The registry compares the hash of the passed 656 authorization information with the hashed authorization information 657 value stored for the object. When the authorization information is 658 not set or the passed authorization information does not match the 659 previously set value, the registry MUST return an EPP error result 660 code of 2202 [RFC5730]. 662 Example of passing a non-empty authorization information in an 663 [RFC5731] domain name info command to verify the authorization 664 information value. 666 C: 667 C: 668 C: 669 C: 670 C: 672 C: example.com 673 C: 674 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP 675 C: 676 C: 677 C: 678 C: 679 C: ABC-12345 680 C: 681 C: 683 The info response in object extensions, such as [RFC5731] and 684 [RFC5733], MUST NOT include the optional authorization information 685 element with a non-empty authorization value. The authorization 686 information is stored as a hash in the registry, so returning the 687 plain text authorization information is not possible, unless a valid 688 plain text authorization information is passed in the info command. 689 The registry MUST NOT return any indication of whether the 690 authorization information is set or unset to the non-sponsoring 691 registrar by not returning the authorization information element in 692 the response. The registry MAY return an indication to the 693 sponsoring registrar that the authorization information is set by 694 using an empty authorization information value. The registry MAY 695 return an indication to the sponsoring registrar that the 696 authorization information is unset by not returning the authorization 697 information element. 699 Example of returning an empty authorization information in an 700 [RFC5731] domain name info response to indicate to the sponsoring 701 registrar that the authorization information is set. 703 S: 704 S: 705 S: 706 S: 707 S: Command completed successfully 708 S: 709 S: 710 S: 712 S: example.com 713 S: EXAMPLE1-REP 714 S: 715 S: ClientX 716 S: 717 S: 718 S: 719 S: 720 S: 721 S: 722 S: ABC-12345 723 S: 54322-XYZ 724 S: 725 S: 726 S: 728 5.4. Transfer Request Command 730 For a Transfer Request Command, the registry MUST allow for the 731 passing of a non-empty authorization information to authorize a 732 transfer. The registry compares the hash of the passed authorization 733 information with the hashed authorization information value stored 734 for the object. When the authorization information is not set or the 735 passed authorization information does not match the previously set 736 value, the registry MUST return an EPP error result code of 2202 737 [RFC5730]. Whether the transfer occurs immediately or is pending is 738 up to server policy. When the transfer occurs immediately, the 739 registry MUST return the EPP success result code of 1000 and when the 740 transfer is pending, the registry MUST return the EPP success result 741 code of 1001. The losing registrar MUST be informed of a successful 742 transfer request using an EPP poll message. 744 Example of passing a non-empty authorization information in an 745 [RFC5731] domain name transfer request command to authorize the 746 transfer. 748 C: 749 C: 750 C: 751 C: 752 C: 754 C: example1.com 755 C: 756 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP 757 C: 758 C: 759 C: 760 C: 761 C: ABC-12345 762 C: 763 C: 765 Upon successful completion of the transfer, the registry MUST 766 automatically unset the authorization information. If the transfer 767 request is not submitted within the time-to-live (TTL) (Section 4.2) 768 or the transfer is cancelled or rejected, the registrar MUST unset 769 the authorization information as defined in Section 5.2. 771 6. Transition Considerations 773 The goal of the transition considerations to the practice defined in 774 this document, referred to as the Secure Authorization Information 775 Model, is to minimize the impact to the registrars by supporting 776 incremental steps of adoption. The transtion steps are dependent on 777 the starting point of the registry. Registries may have different 778 starting points, since some of the elements of the Secure 779 Authorization Information Model may have already been implemented. 780 The considerations assume a starting point, referred to as the 781 Classic Authorization Information Model, that have the following 782 steps in the management of the authorization information for 783 transfers: 785 1. Registrant requests to register the object with the registrar. 786 Registrar sends the create command, with a non-empty 787 authorization information, to the registry. The registry stores 788 the authorization information as an encrypted value and requires 789 a non-empty authorization information for the life of the object. 790 The registrar may store the long-lived authorization information. 792 2. At the time of transfer, Registrant requests from the losing 793 registrar the authorization information to provide to the gaining 794 registrar. 795 3. Losing registrar retrieves the stored authorization information 796 locally or queries the registry for authorization information 797 using the info command, and provides it to the registrant. If 798 the registry is queried, the authorization information is 799 decrypted and the plain text authorization information is 800 returned in the info response to the registrar. 801 4. Registrant provides the authorization information value to the 802 gaining registrar. 803 5. Gaining registrar optionally verifies the authorization 804 information with the info command to the registry, by passing the 805 authorization information in the info command to the registry. 806 6. Gaining registrar sends the transfer request with the 807 authorization information to the registry. The registry will 808 decrypt the stored authorization information to compare to the 809 passed authorization information. 810 7. If the transfer successfully completes, the authorization 811 information is not touched by the registry and may be updated by 812 the gaining registrar using the update command. If the transfer 813 is cancelled or rejected, the losing registrar may reset the 814 authorization information using the update command. 816 The gaps between the Classic Authorization Information Model and the 817 Secure Authorization Information Model include: 819 1. Registry requirement for a non-empty authorization information on 820 create and for the life of the object versus the authorization 821 information not being set on create and only being set when a 822 transfer is in process. 823 2. Registry not allowing the authorization information to be unset 824 versus supporting the authorization to be unset in the update 825 command. 826 3. Registry storing the authorization information as an encrypted 827 value versus as a hashed value. 828 4. Registry support for returning the authorization information 829 versus not returning the authorization information in the info 830 response. 831 5. Registry not touching the authorization information versus the 832 registry automatically unsetting the authorization information 833 upon a successful transfer. 834 6. Registry may validate a shorter authorization information value 835 using password complexity rules versus validating the randomness 836 of a longer authorization information value that meets the 837 required bits of entropy. 839 The transition can be handled in the three phases defined in the sub- 840 sections Section 6.1, Section 6.2, Section 6.3. 842 6.1. Transition Phase 1 - Features 844 The goal of the "Transition Phase 1 - Features" is to implement the 845 needed features in EPP so that the registrar can optionally implement 846 the Secure Authorization Information Model. The features to 847 implement are broken out by the command and responses below: 849 Create Command: Change the create command to make the authorization 850 information optional, by allowing both a non-empty value and an 851 empty value. This enables a registrar to optionally create 852 objects without an authorization information value, as defined in 853 Section 5.1. 854 Update Command: Change the update command to allow unsetting the 855 authorization information, as defined in Section 5.2. This 856 enables the registrar to optionally unset the authorization 857 information when the TTL expires or when the transfer is cancelled 858 or rejected. 859 Transfer Approve Command and Transfer Auto-Approve: Change the 860 transfer approve command and the transfer auto-approve to 861 automatically unset the authorization information. This sets the 862 default state of the object to not have the authorization 863 information set. The registrar implementing the Secure 864 Authorization Information Model will not set the authorization 865 information for an inbound transfer and the registrar implementing 866 the Classic Authorization Information Model will set the new 867 authorization information upon the successful transfer. 868 Info Response: Change the info command to not return the 869 authorization information in the info response, as defined in 870 Section 5.3. This sets up the implementation of "Transition Phase 871 2 - Storage", since the dependency in returning the authorization 872 information in the info response will be removed. This feature is 873 the only one that is not an optional change to the registrar. 874 Info Command and Transfer Request: Change the info command and the 875 transfer request to ensure that a registrar cannot get an 876 indication that the authorization information is set or not set by 877 returning the EPP error result code of 2202 when comparing a 878 passed authorization to a non-matching set authorization 879 information value or an unset value. 881 6.2. Transition Phase 2 - Storage 883 The goal of the "Transition Phase 2 - Storage" is to transition the 884 registry to use hashed authorization information instead of encrypted 885 authorization information. There is no direct impact to the 886 registrars, since the only visible indication that the authorization 887 information has been hashed is by not returning the set authorization 888 information in the info response, which is addressed in Transition 889 Phase 1 - Features (Section 6.1). There are three steps to 890 transition the authorization information storage, which includes: 892 Hash New Authorization Information Values: Change the create command 893 and the update command to hash instead of encyrpting the 894 authorization information. 895 Supporting Comparing Against Encrypted and Hashed Authorization 896 Information: 897 Change the info command and the transfer request command to be 898 able to compare a passed authorization information value with 899 either a hashed or encyrpted authorization information value. 900 Hash Existing Encrypted Authorization Information Values: Convert 901 the encrypted authorization information values stored in the 902 registry database to hashed values. The update is not a visible 903 change to the registrar. The conversion can be done over a period 904 of time depending on registry policy. 906 6.3. Transition Phase 3 - Enforcement 908 The goal of the "Transition Phase 3 - Enforcement" is to complete the 909 implementation of the "Secure Authorization Information Model", by 910 enforcing the following: 912 Disallow Authorization Information on Create Command: Change the 913 create command to not allow for the passing of a non-empty 914 authorization information value. 915 Validate the Strong Random Authorization Information: Change the 916 validation of the authorization information in the update command 917 to ensure at least 128 bits of entropy. 919 7. IANA Considerations 921 7.1. XML Namespace 923 This document uses URNs to describe XML namespaces conforming to a 924 registry mechanism described in [RFC3688]. The following URI 925 assignment is requested of IANA: 927 Registration request for the secure authorization information for 928 transfer namespace: 930 URI: urn:ietf:params:xml:ns:epp:secure-authinfo-transfer-1.0 931 Registrant Contact: IESG 932 XML: None. Namespace URIs do not represent an XML specification. 934 7.2. EPP Extension Registry 936 The EPP Best Current Practice (BCP) described in this document should 937 be registered by the IANA in the EPP Extension Registry described in 938 [RFC7451]. The details of the registration are as follows: 940 Name of Extension: "Extensible Provisioning Protocol (EPP) Secure 941 Authorization Information for Transfer" 943 Document status: Best Current Practice 945 Reference: (insert reference to RFC version of this document) 947 Registrant Name and Email Address: IESG, 949 TLDs: Any 951 IPR Disclosure: None 953 Status: Active 955 Notes: None 957 8. Implementation Status 959 Note to RFC Editor: Please remove this section and the reference to 960 RFC 7942 [RFC7942] before publication. 962 This section records the status of known implementations of the 963 protocol defined by this specification at the time of posting of this 964 Internet-Draft, and is based on a proposal described in RFC 7942 965 [RFC7942]. The description of implementations in this section is 966 intended to assist the IETF in its decision processes in progressing 967 drafts to RFCs. Please note that the listing of any individual 968 implementation here does not imply endorsement by the IETF. 969 Furthermore, no effort has been spent to verify the information 970 presented here that was supplied by IETF contributors. This is not 971 intended as, and must not be construed to be, a catalog of available 972 implementations or their features. Readers are advised to note that 973 other implementations may exist. 975 According to RFC 7942 [RFC7942], "this will allow reviewers and 976 working groups to assign due consideration to documents that have the 977 benefit of running code, which may serve as evidence of valuable 978 experimentation and feedback that have made the implemented protocols 979 more mature. It is up to the individual working groups to use this 980 information as they see fit". 982 8.1. Verisign EPP SDK 984 Organization: Verisign Inc. 986 Name: Verisign EPP SDK 988 Description: The Verisign EPP SDK includes both a full client 989 implementation and a full server stub implementation of draft-ietf- 990 regext-secure-authinfo-transfer. 992 Level of maturity: Development 994 Coverage: All aspects of the protocol are implemented. 996 Licensing: GNU Lesser General Public License 998 Contact: jgould@verisign.com 1000 URL: https://www.verisign.com/en_US/channel-resources/domain- 1001 registry-products/epp-sdks 1003 8.2. RegistryEngine EPP Service 1005 Organization: CentralNic 1007 Name: RegistryEngine EPP Service 1009 Description: Generic high-volume EPP service for gTLDs, ccTLDs and 1010 SLDs 1012 Level of maturity: Deployed in CentralNic's production environment as 1013 well as two other gTLD registry systems, and two ccTLD registry 1014 systems. 1016 Coverage: Authorization Information is "write only" in that the 1017 registrars can set the Authorization Information, but not get the 1018 Authorization Information in the Info Response. 1020 Licensing: Proprietary In-House software 1022 Contact: epp@centralnic.com 1024 URL: https://www.centralnic.com 1026 9. Security Considerations 1028 Section 4.1 defines the use a secure random value for the generation 1029 of the authorization information. The server SHOULD define policy 1030 related to the length and set of characters that are included in the 1031 randomization to target the desired entropy level, with the 1032 recommendation of at least 49 bits for entropy. The authorization 1033 information server policy is communicated to the client using an out- 1034 of-band process. The client SHOULD choose a length and set of 1035 characters that results in entropy that meets or exceeds the server 1036 policy. A random number generator (RNG) is preferable over the use 1037 of a pseudorandom number generator (PRNG) when creating the 1038 authorization information value. 1040 Section 4.2 defines the use of an authorization information Time-To- 1041 Live (TTL). The registrar SHOULD only set the authorization 1042 information during the transfer process by the server support for 1043 setting and unsetting the authorization information. The TTL value 1044 is up to registrar policy and the sponsoring registrar MUST inform 1045 the registrant of the TTL when providing the authorization 1046 information to the registrant. 1048 Section 4.3 defines the storage and transport of authorization 1049 information. The losing registrar MUST NOT store the authorization 1050 information and the gaining registrar MUST only store the 1051 authorization information as a "transient" value during the transfer 1052 process, where the authorization information MUST NOT be stored after 1053 the end of the transfer process. The registry MUST store the 1054 authorization information using a one-way cryptographic hash of at 1055 least 256 bits and with a random salt. All communication that 1056 includes the authorization information MUST be over an encrypted 1057 channel. The plain text authorization information MUST NOT be 1058 written to any logs by the registrar or the registry. 1060 Section 4.4 defines the matching of the authorization information 1061 values. The registry stores an unset authorization information as a 1062 NULL (undefined) value to ensure that an empty input authorization 1063 information never matches it. The method used to define a NULL 1064 (undefined) value is database specific. 1066 10. Acknowledgements 1068 The authors wish to thank the following persons for their feedback 1069 and suggestions: 1071 o Michael Bauland 1072 o Martin Casanova 1073 o Scott Hollenbeck 1074 o Jody Kolker 1075 o Patrick Mevzek 1076 o Matthew Pozun 1077 o Srikanth Veeramachaneni 1078 o Ulrich Wisser 1080 11. References 1082 11.1. Normative References 1084 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1085 Requirement Levels", BCP 14, RFC 2119, 1086 DOI 10.17487/RFC2119, March 1997, 1087 . 1089 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1090 DOI 10.17487/RFC3688, January 2004, 1091 . 1093 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1094 "Randomness Requirements for Security", BCP 106, RFC 4086, 1095 DOI 10.17487/RFC4086, June 2005, 1096 . 1098 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1099 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1100 . 1102 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1103 Domain Name Mapping", STD 69, RFC 5731, 1104 DOI 10.17487/RFC5731, August 2009, 1105 . 1107 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1108 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 1109 August 2009, . 1111 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1112 Transport over TCP", STD 69, RFC 5734, 1113 DOI 10.17487/RFC5734, August 2009, 1114 . 1116 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1117 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1118 February 2015, . 1120 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1121 Code: The Implementation Status Section", BCP 205, 1122 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1123 . 1125 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1126 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1127 January 2019, . 1129 11.2. URIs 1131 [1] https://csrc.nist.gov/publications/detail/fips/140/2/final 1133 Appendix A. Change History 1135 A.1. Change from 00 to 01 1137 1. Filled in the "Implementation Status" section with the inclusion 1138 of the "Verisign EPP SDK" and "RegistryEngine EPP Service" 1139 implementations. 1140 2. Made small wording corrections based on private feedback. 1141 3. Added content to the "Acknowledgements" section. 1143 A.2. Change from 01 to 02 1145 1. Revised the language used for the storage of the authorization 1146 information based on the feedback from Patrick Mevzek and Jody 1147 Kolker. 1149 A.3. Change from 02 to 03 1151 1. Updates based on the feedback from the interim REGEXT meeting 1152 held at ICANN-66: 1154 1. Section 3.3, include a reference to the hash algorithm to 1155 use. Broke the requirements into a list and included a the 1156 reference the text ', with at least a 256-bit hash function, 1157 such as SHA-256'. 1158 2. Add a Transition Considerations section to cover the 1159 transition from the classic authorization information 1160 security model in the EPP RFCs to the model defined in the 1161 document. 1162 3. Add a statement to the Introduction that elements of the 1163 practice can be used for purposes other than transfer, but 1164 with a caveat. 1165 2. Updates based on the review by Michael Bauland, that include: 1167 1. In section 2, change 'there are three actors' to 'there are 1168 three types of actors' to cover the case with transfers that 1169 has two registrar actors (losing and gaining). 1170 2. In section 3.1, change the equations equals to be 1171 approximately equal by using '=~' instead of '=', where 1172 applicable. 1173 3. In section 3.3, change 'MUST be over an encrypted channel, 1174 such as [RFC5734]'' to 'MUST be over an encrypted channel, 1175 such as defined in [RFC5734]''. 1176 4. In section 4.1, remove the optional RFC 5733 elements from 1177 the contact create, which includes the , 1178 , , , 1179 , , and elements. 1180 5. In section 4.2, changed 'Example of unsetting the 1181 authorization information explicitly in an [RFC5731] domain 1182 name update command.' to 'Example of adding the 1183 "clientTransferProhibited" status and unsetting the 1184 authorization information explicitly in an [RFC5731] domain 1185 name update command.' 1186 6. In section 4.3, cover a corner case of the ability to return 1187 the authorization information when it's passed in the info 1188 command. 1189 7. In section 4.4, change 'If the transfer does not complete 1190 within the time-to-live (TTL)' to 'If the transfer is not 1191 initiated within the time-to-live (TTL)', since the TTL is 1192 the time between setting the authorization information and 1193 when it's successfully used in a transfer request. Added the 1194 case of unsetting the authorization information when the 1195 transfer is cancelled or rejected. 1196 3. Updates based on the authorization information messages by Martin 1197 Casanova on the REGEXT mailing list, that include: 1199 1. Added section 3.4 'Authorization Information Matching' to 1200 clarify how the authorization information is matched, when 1201 there is set and unset authorization information in the 1202 database and empty and non-empty authorization information 1203 passed in the info and transfer commands. 1204 2. Added support for signaling that the authorization 1205 information is set or unset to the sponsoring registrar with 1206 the inclusion of an empty authorization information element 1207 in the response to indicate that the authorization 1208 information is set and the exclusion of the authorization 1209 information element in the response to indicate that the 1210 authorization information is unset. 1211 4. Made the capitalization of command and response references 1212 consistent by uppercasing section and item titles and lowercasing 1213 references elsewhere. 1215 A.4. Change from 03 to REGEXT 00 1217 1. Changed to regext working group draft by changing draft-gould- 1218 regext-secure-authinfo-transfer to draft-ietf-regext-secure- 1219 authinfo-transfer. 1221 A.5. Change from REGEXT 00 to REGEXT 01 1223 1. Added the "Signaling Client and Server Support" section to 1224 describe the mechanism to signal support for the BCP by the 1225 client and the server. 1226 2. Added the "IANA Considerations" section with the registration of 1227 the secure authorization for transfer XML namespace and the 1228 registration of the EPP Best Current Practice (BCP) in the EPP 1229 Extension Registry. 1231 A.6. Change from REGEXT 01 to REGEXT 02 1233 1. Added inclusion of random salt for the hashed authorization 1234 information, based on feedback from Ulrich Wisser. 1235 2. Added clarification that the representation of a NULL (undefined) 1236 value is dependent on the type of database, based on feedback 1237 from Patrick Mevzek. 1238 3. Filled in the Security Considerations section. 1240 A.7. Change from REGEXT 02 to REGEXT 03 1242 1. Updated the XML namespace to urn:ietf:params:xml:ns:epp:secure- 1243 authinfo-transfer-1.0, which removed bcp from the namespace and 1244 bumped the version from 0.1 and 1.0. Inclusion of bcp in the XML 1245 namespace was discussed at the REGEXT interim meeting. 1246 2. Replaced Auhtorization with Authorization based on a review by 1247 Jody Kolker. 1249 Authors' Addresses 1251 James Gould 1252 VeriSign, Inc. 1253 12061 Bluemont Way 1254 Reston, VA 20190 1255 US 1257 Email: jgould@verisign.com 1258 URI: http://www.verisign.com 1259 Richard Wilhelm 1260 VeriSign, Inc. 1261 12061 Bluemont Way 1262 Reston, VA 20190 1263 US 1265 Email: rwilhelm@verisign.com 1266 URI: http://www.verisign.com