idnits 2.17.1 draft-ietf-regext-secure-authinfo-transfer-01.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 (April 23, 2020) is 1464 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 1087 ** 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: October 25, 2020 April 23, 2020 7 Extensible Provisioning Protocol (EPP) Secure Authorization Information 8 for Transfer 9 draft-ietf-regext-secure-authinfo-transfer-01 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 October 25, 2020. 49 Copyright Notice 51 Copyright (c) 2020 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (https://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the Simplified BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 67 1.1. Conventions Used in This Document . . . . . . . . . . . . 4 68 2. Registrant, Registrar, Registry . . . . . . . . . . . . . . . 5 69 3. 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 . . . . . . . . . . . . . . . . . . . . . . . . . 23 93 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 94 11.2. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 24 95 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 24 96 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 24 97 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 24 98 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 24 99 A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 26 100 A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 26 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 26 103 1. Introduction 105 The Extensible Provisioning Protocol (EPP), in [RFC5730], defines the 106 use of authorization information to authorize a transfer. The 107 authorization information is object-specific and has been defined in 108 the EPP Domain Name Mapping, in [RFC5731], and the EPP Contact 109 Mapping, in [RFC5733], as password-based authorization information. 110 Other authorization mechanisms can be used, but in practice the 111 password-based authorization information has been used at the time of 112 object create, managed with the object update, and used to authorize 113 an object transfer request. What has not been considered is the 114 security of the authorization information that includes the 115 complexity of the authorization information, the time-to-live (TTL) 116 of the authorization information, and where and how the authorization 117 information is stored. This document defines an operational 118 practice, using the EPP RFCs, that leverages the use of strong, 119 random authorization information values that are short-lived, that 120 are not stored by the client, and that are stored by the server using 121 a cryptographic hash to provide, for secure authorization information 122 used for transfers. This operational practice can be used to support 123 transfers of any EPP object, where the domain name object defined in 124 [RFC5731] is used in this document for illustration purposes. 125 Elements of the practice may be used to support the secure use of the 126 authorization information for purposes other than transfer, but any 127 other purposes and the applicable elements are out-of-scope for this 128 document. 130 The overall goal is to have strong, random authorization information 131 values, that are short-lived, and that are either not stored or 132 stored as a cryptographic hash values by the non-responsible parties. 133 In a registrant, registrar, and registry model, the registrant 134 registers the object through the registrar to the registry. The 135 registrant is the responsible party and the registrar and the 136 registry are the non-responsible parties. EPP is a protocol between 137 the registrar and the registry, where the registrar is referred to as 138 the client and the registry is referred to as the server. The 139 following are the elements of the operational practice and how the 140 existing features of the EPP RFCs can be leveraged to satisfy them: 142 "Strong Random Authorization Information": The EPP RFCs define the 143 password-based authorization information value using an XML 144 schema "normalizedString" type, so they don't restrict what can 145 be used in any way. This operational practice defines the 146 recommended mechanism for creating a strong random authorization 147 value, that would be generated by the client. 148 "Short-Lived Authorization Information": The EPP RFCs don't 149 explicitly support short-lived authorization information or a 150 time-to-live (TTL) for authorization information, but there are 151 EPP RFC features that can be leveraged to support short-lived 152 authorization information. If authorization information is set 153 only when there is a transfer in process, the server needs to 154 support empty authorization information on create, support 155 setting and unsetting authorization information, and support 156 automatically unsetting the authorization information upon a 157 successful transfer. All of these features can be supported by 158 the EPP RFCs. 159 "Storing Authorization Information Securely": The EPP RFCs don't 160 specify where and how the authorization information is stored in 161 the client or the server, so there are no restrictions to define 162 an operational practice for storing the authorization information 163 securely. The operational practice will not require the client 164 to store the authorization information and will require the 165 server to store the authorization information using a 166 cryptographic hash, with at least a 256-bit hash function, such 167 as SHA-256. Returning the authorization information set in an 168 EPP info response will not be supported. 170 1.1. Conventions Used in This Document 172 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 173 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 174 document are to be interpreted as described in RFC 2119 [RFC2119]. 176 XML is case sensitive. Unless stated otherwise, XML specifications 177 and examples provided in this document MUST be interpreted in the 178 character case presented in order to develop a conforming 179 implementation. 181 In examples, "C:" represents lines sent by a protocol client and "S:" 182 represents lines returned by a protocol server. Indentation and 183 white space in examples are provided only to illustrate element 184 relationships and are not a required feature of this protocol. 186 The examples reference XML namespace prefixes that are used for the 187 associated XML namespaces. Implementations MUST NOT depend on the 188 example XML namespaces and instead employ a proper namespace-aware 189 XML parser and serializer to interpret and output the XML documents. 190 The example namespace prefixes used and their associated XML 191 namespaces include: 193 "domain": urn:ietf:params:xml:ns:domain-1.0 194 "contact": urn:ietf:params:xml:ns:contact-1.0 196 2. Registrant, Registrar, Registry 198 The EPP RFCs refer to client and server, but when it comes to 199 transfers, there are three types of actors that are involved. This 200 document will refer to the actors as registrant, registrar, and 201 registry. [RFC8499] defines these terms formally for the Domain Name 202 System (DNS). The terms are further described below to cover their 203 roles as actors of using the authorization information in the 204 transfer process of any object in the registry, such as a domain name 205 or a contact: 207 "registrant": [RFC8499] defines the registrant as "an individual or 208 organization on whose behalf a name in a zone is registered by 209 the registry". The registrant can be the owner of any object in 210 the registry, such as a domain name or a contact. The registrant 211 interfaces with the registrar for provisioning the objects. A 212 transfer is coordinated by the registrant to transfer the 213 sponsorship of the object from one registrar to another. The 214 authorization information is meant to authenticate the registrant 215 as the owner of the object to the non-sponsoring registrar and to 216 authorize the transfer. 217 "registrar": [RFC8499] defines the registrar as "a service provider 218 that acts as a go-between for registrants and registries". The 219 registrar interfaces with the registrant for the provisioning of 220 objects, such as domain names and contacts, and with the 221 registries to satisfy the registrant's provisioning requests. A 222 registrar may directly interface with the registrant or may 223 indirectly interface with the registrant, typically through one 224 or more resellers. Implementing a transfer using secure 225 authorization information extends through the registrar's 226 reseller channel up to the direct interface with the registrant. 227 The registrar's interface with the registries uses EPP. The 228 registrar's interface with its reseller channel or the registrant 229 is registrar-specific. In the EPP RFCs, the registrar is 230 referred to as the "client", since EPP is the protocol used 231 between the registrar and the registry. The sponsoring registrar 232 is the authorized registrar to manage objects on behalf of the 233 registrant. A non-sponsoring registrar is not authorized to 234 manage objects on behalf of the registrant. A transfer of an 235 object's sponsorship is from one registrar, referred to as the 236 losing registrar, to another registrar, referred to as the 237 gaining registrar. 238 "registry": [RFC8499] defines the registry as "the administrative 239 operation of a zone that allows registration of names within the 240 zone". The registry typically interfaces with the registrars 241 over EPP and generally does not interact directly with the 242 registrant. In the EPP RFCs, the registry is referred to as the 243 "server", since EPP is the protocol used between the registrar 244 and the registry. The registry has a record of the sponsoring 245 registrar for each object and provides the mechanism (over EPP) 246 to coordinate a transfer of an object's sponsorship between 247 registrars. 249 3. Signaling Client and Server Support 251 This document does not define new protocol but a Best Current 252 Practice (BCP) using the existing EPP protocol, where the client and 253 the server can signal support for the BCP using a namespace URI in 254 the login and greeting extension services. The namespace URI 255 "urn:ietf:params:xml:ns:epp:bcp:secure-authinfo-transfer-0.1" is used 256 to signal support for the BCP. The client includes the namespace URI 257 in an element of the [RFC5730] 258 Command. The server includes the namespace URI in an 259 element of the [RFC5730] Greeting. 261 A client that receives the namespace URI in the server's Greeting 262 extension services, can expect the following supported behavior by 263 the server: 265 1. Support empty authorization information with a create command. 266 2. Support unsetting authorization information with an update 267 command. 268 3. Support validating authorization information with an info 269 command. 270 4. Support not returning an indication whether the authorization 271 information is set or unset to the non-sponsoring registrar. 272 5. Support returning empty authorization information to sponsoring 273 registrar when the authorization information is set in an info 274 response. 275 6. Support allowing for the passing of a matching non-empty 276 authorization information to authorize a transfer. 277 7. Support automatically unsetting the authorization information 278 upon a successful completion of transfer. 280 A server that receives the namespace URI in the client's 281 Command extension services, can expect the following supported 282 behavior by the client: 284 1. Support generation of authorization information using a secure 285 random value. 286 2. Support only setting the authorization information when there is 287 a transfer in process. 289 4. Secure Authorization Information 291 The authorization information in the EPP RFCs ([RFC5731] and 292 [RFC5733]) that support transfer use password-based authorization 293 information. Other EPP objects that support password-based 294 authorization information for transfer can use the Secure 295 Authorization Information defined in this document. For the 296 authorization information to be secure it must be a strong random 297 value and must have a short time-to-live (TTL). The security of the 298 authorization information is defined in the following sections. 300 4.1. Secure Random Authorization Information 302 For authorization information to be secure, it MUST be generated 303 using a secure random value. The authorization information is 304 treated as a password, where according to [RFC4086] a high-security 305 password must have at least 49 bits of randomness or entropy. The 306 required length L of a password, rounded up to the largest whole 307 number, is based on the set of characters N and the desired entropy 308 H, in the equation L = ROUNDUP(H / log2 N). With a target entropy of 309 49, the required length can be calculated after deciding on the set 310 of characters that will be randomized. The following are a set of 311 possible character sets and the calculation of the required length. 313 Calculation of the required length with 49 bits of entropy and with 314 the set of all printable ASCII characters except space (0x20), which 315 consists of the 94 characters 0x21-0x7E. 317 ROUNDUP(49 / log2 94) =~ ROUNDUP(49 / 6.55) =~ ROUNDUP(7.48) = 8 319 Calculation of the required length with 49 bits of entropy and with 320 the set of case-insensitive alphanumeric characters, which consists 321 of 36 characters (a-z A-Z 0-9). 323 ROUNDUP(49 / log2 36) =~ ROUNDUP(49 / 5.17) =~ ROUNDUP(9.48) = 10 325 Considering the age of [RFC4086], the evolution of security 326 practices, and that the authorization information is a machine- 327 generated value, the recommendation is to use at least 128 bits of 328 entropy. The lengths are recalculated below using 128 bits of 329 entropy. 331 Calculation of the required length with 128 bits of entropy and with 332 the set of all printable ASCII characters except space (0x20), which 333 consists of the 94 characters 0x21-0x7E. 335 ROUNDUP(128 / log2 94) =~ ROUNDUP(128 / 6.55) =~ ROUNDUP(19.54) = 20 336 Calculation of the required length with 128 bits of entropy and with 337 the set of case insensitive alphanumeric characters, which consists 338 of 36 characters (a-z A-Z 0-9). 340 ROUNDUP(128 / log2 36) =~ ROUNDUP(128 / 5.17) =~ ROUNDUP(24.76) = 25 342 The strength of the random authorization information is dependent on 343 the actual entropy of the underlying random number generator. For 344 the random number generator, the practices defined in [RFC4086] and 345 section 4.7.1 of the NIST Federal Information Processing Standards 346 (FIPS) Publication 140-2 [1] SHOULD be followed to produce random 347 values that will be resistant to attack. A random number generator 348 (RNG) is preferable over the use of a pseudorandom number generator 349 (PRNG) to reduce the predictability of the authorization information. 350 The more predictable the random number generator is, the lower the 351 true entropy, and the longer the required length for the 352 authorization information. 354 4.2. Authorization Information Time-To-Live (TTL) 356 The authorization information SHOULD only be set when there is a 357 transfer in process. This implies that the authorization information 358 has a Time-To-Live (TTL) by which the authorization information is 359 cleared when the TTL expires. The EPP RFCs have no definition of 360 TTL, but since the server supports the setting and unsetting of the 361 authorization information by the sponsoring registrar, then the 362 sponsoring registrar can apply a TTL based on client policy. The TTL 363 client policy may be based on proprietary registrar-specific criteria 364 which provides for a transfer-specific TTL tuned for the particular 365 circumstances of the transaction. The sponsoring registrar will be 366 aware of the TTL and the sponsoring registrar MUST inform the 367 registrant of the TTL when the authorization information is provided 368 to the registrant. 370 4.3. Authorization Information Storage and Transport 372 To protect the disclosure of the authorization information, the 373 following requirements apply: 375 1. The authorization information MUST be stored by the registry 376 using a strong one-way cryptographic hash, with at least a 377 256-bit hash function, such as SHA-256. 378 2. An empty authorization information MUST be stored with a NULL 379 (undefined) value. 380 3. The authorization information MUST NOT be stored by the losing 381 registrar. 383 4. The authorization information MUST only be stored by the gaining 384 registrar as a "transient" value in support of the transfer 385 process. 386 5. The plain text version of the authorization information MUST NOT 387 be written to any logs by the registrar or the registry. 388 6. All communication that includes the authorization information 389 MUST be over an encrypted channel, such as defined in [RFC5734] 390 for EPP. 391 7. The registrar's interface for communicating the authorization 392 information with the registrant MUST be over an authenticated and 393 encrypted channel. 395 4.4. Authorization Information Matching 397 To support the authorization information TTL, as defined in 398 Section 4.2, the authorization information must have either a set or 399 unset state. The unset authorization information is stored with a 400 NULL (undefined) value. Based on the requirement to store the 401 authorization information using a strong one-way cryptographic hash, 402 as defined in Section 4.3, a set authorization information is stored 403 with a non-NULL hashed value. The empty authorization information is 404 used as input in both the create command (Section 5.1) and the update 405 command (Section 5.2) to define the unset state. The matching of the 406 authorization information in the info command (Section 5.3) and the 407 transfer request command (Section 5.4) is based on the following 408 rules: 410 1. Any input authorization information value MUST NOT match an unset 411 authorization information value. 412 2. An empty input authorization information value MUST NOT match any 413 authorization information value. 414 3. A non-empty input authorization information value MUST be hashed 415 and matched against the set authorization information value, 416 which is stored using the same hash algorithm. 418 5. Create, Transfer, and Secure Authorization Information 420 To make the transfer process secure using secure authorization 421 information, as defined in Section 4, the client and server need to 422 implement steps where the authorization information is set only when 423 a transfer is actively in process and ensure that the authorization 424 information is stored securely and transported only over secure 425 channels. The steps in management of the authorization information 426 for transfers include: 428 1. Registrant requests to register the object with the registrar. 429 Registrar sends the create command, with empty authorization 430 information, to the registry, as defined in Section 5.1. 432 2. Registrant requests from the losing registrar the authorization 433 information to provide to the gaining registrar. 434 3. Losing registrar generates a secure random authorization 435 information value, sends it to the registry as defined in 436 Section 5.2, and provides it to the registrant. 437 4. Registrant provides the authorization information value to the 438 gaining registrar. 439 5. Gaining registrar optionally verifies the authorization 440 information with the info command to the registry, as defined in 441 Section 5.3. 442 6. Gaining registrar sends the transfer request with the 443 authorization information to the registry, as defined in 444 Section 5.4. 445 7. If the transfer successfully completes, the registry 446 automatically unsets the authorization information; otherwise the 447 losing registrar unsets the authorization information when the 448 TTL expires, as defined in Section 5.2. 450 The following sections outline the practices of the EPP commands and 451 responses between the registrar and the registry that supports secure 452 authorization information for transfer. 454 5.1. Create Command 456 For a create command, the registry MUST allow for the passing of an 457 empty authorization information and MAY disallow for the passing of a 458 non-empty authorization information. By having an empty 459 authorization information on create, the object is initially not in 460 the transfer process. Any EPP object extension that supports setting 461 the authorization information with a "eppcom:pwAuthInfoType" element, 462 can have an empty authorization information passed, such as [RFC5731] 463 and [RFC5733]. 465 Example of passing empty authorization information in an [RFC5731] 466 domain name create command. 468 C: 469 C: 470 C: 471 C: 472 C: 474 C: example.com 475 C: 476 C: 477 C: 478 C: 479 C: 480 C: ABC-12345 481 C: 482 C: 484 Example of passing empty authorization information in an [RFC5733] 485 contact create command. 487 C: 488 C: 489 C: 490 C: 491 C: 493 C: sh8013 494 C: 495 C: John Doe 496 C: 497 C: Dulles 498 C: US 499 C: 500 C: 501 C: jdoe@example.com 502 C: 503 C: 504 C: 505 C: 506 C: 507 C: ABC-12345 508 C: 509 C: 511 5.2. Update Command 513 For an update command, the registry MUST allow for the setting and 514 unsetting of the authorization information. The registrar sets the 515 authorization information by first generating a strong, random 516 authorization information value, based on Section 4.1, and setting it 517 in the registry in the update command. The registry SHOULD validate 518 the randomness of the authorization information based on the length 519 and character set required by the registry. For example, a registry 520 that requires 20 random printable ASCII characters except space 521 (0x20), should validate that the authorization information contains 522 at least one upper case alpha character, one lower case alpha 523 character, and one non-alpha numeric character. If the authorization 524 information fails the randomness validation, the registry MUST return 525 an EPP error result code of 2202. 527 Often the registrar has the "clientTransferProhibited" status set, so 528 to start the transfer process, the "clientTransferProhibited" status 529 needs to be removed, and the strong, random authorization information 530 value needs to be set. The registrar MUST define a time-to-live 531 (TTL), as defined in Section 4.2, where if the TTL expires the 532 registrar will unset the authorization information. 534 Example of removing the "clientTransferProhibited" status and setting 535 the authorization information in an [RFC5731] domain name update 536 command. 538 C: 539 C: 540 C: 541 C: 542 C: 544 C: example.com 545 C: 546 C: 547 C: 548 C: 549 C: 550 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP 551 C: 552 C: 553 C: 554 C: 555 C: 556 C: ABC-12345-XYZ 557 C: 558 C: 559 When the registrar-defined TTL expires, the sponsoring registrar 560 cancels the transfer process by unsetting the authorization 561 information value and may add back statuses like the 562 "clientTransferProbited" status. Any EPP object extension that 563 supports setting the authorization information with a 564 "eppcom:pwAuthInfoType" element, can have an empty authorization 565 information passed, such as [RFC5731] and [RFC5733]. Setting an 566 empty authorization information unsets the value. [RFC5731] supports 567 an explicit mechanism of unsetting the authorization information, by 568 passing the authorization information value. The 569 registry MUST support unsetting the authorization information by 570 accepting an empty authorization information value and accepting an 571 explicit unset element if it is supported by the object extension. 573 Example of adding the "clientTransferProhibited" status and unsetting 574 the authorization information explicitly in an [RFC5731] domain name 575 update command. 577 C: 578 C: 579 C: 580 C: 581 C: 583 C: example.com 584 C: 585 C: 586 C: 587 C: 588 C: 589 C: 590 C: 591 C: 592 C: 593 C: 594 C: ABC-12345-XYZ 595 C: 596 C: 597 Example of unsetting the authorization information with an empty 598 authorization information in an [RFC5731] domain name update command. 600 C: 601 C: 602 C: 603 C: 604 C: 606 C: example.com 607 C: 608 C: 609 C: 610 C: 611 C: 612 C: 613 C: 614 C: 615 C: 616 C: 617 C: ABC-12345-XYZ 618 C: 619 C: 621 Example of unsetting the authorization information with an empty 622 authorization information in an [RFC5733] contact update command. 624 C: 625 C: 626 C: 627 C: 628 C: 630 C: sh8013 631 C: 632 C: 633 C: 634 C: 635 C: 636 C: 637 C: 638 C: ABC-12345-XYZ 639 C: 640 C: 642 5.3. Info Command and Response 644 For an info command, the registry MUST allow for the passing of a 645 non-empty authorization information for verification. The gaining 646 registrar can pre-verify the authorization information provided by 647 the registrant prior to submitting the transfer request with the use 648 of the info command. The registry compares the hash of the passed 649 authorization information with the hashed authorization information 650 value stored for the object. When the authorization information is 651 not set or the passed authorization information does not match the 652 previously set value, the registry MUST return an EPP error result 653 code of 2202 [RFC5730]. 655 Example of passing a non-empty authorization information in an 656 [RFC5731] domain name info command to verify the authorization 657 information value. 659 C: 660 C: 661 C: 662 C: 663 C: 665 C: example.com 666 C: 667 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP 668 C: 669 C: 670 C: 671 C: 672 C: ABC-12345 673 C: 674 C: 676 The info response in object extensions, such as [RFC5731] and 677 [RFC5733], MUST NOT include the optional authorization information 678 element with a non-empty authorization value. The authorization 679 information is stored as a hash in the registry, so returning the 680 plain text authorization information is not possible, unless a valid 681 plain text authorization information is passed in the info command. 682 The registry MUST NOT return any indication of whether the 683 authorization information is set or unset to the non-sponsoring 684 registrar by not returning the authorization information element in 685 the response. The registry MAY return an indication to the 686 sponsoring registrar that the authorization information is set by 687 using an empty authorization information value. The registry MAY 688 return an indication to the sponsoring registrar that the 689 authorization information is unset by not returning the authorization 690 information element. 692 Example of returning an empty authorization information in an 693 [RFC5731] domain name info response to indicate to the sponsoring 694 registrar that the authorization information is set. 696 S: 697 S: 698 S: 699 S: 700 S: Command completed successfully 701 S: 702 S: 703 S: 705 S: example.com 706 S: EXAMPLE1-REP 707 S: 708 S: ClientX 709 S: 710 S: 711 S: 712 S: 713 S: 714 S: 715 S: ABC-12345 716 S: 54322-XYZ 717 S: 718 S: 719 S: 721 5.4. Transfer Request Command 723 For a Transfer Request Command, the registry MUST allow for the 724 passing of a non-empty authorization information to authorize a 725 transfer. The registry compares the hash of the passed authorization 726 information with the hashed authorization information value stored 727 for the object. When the authorization information is not set or the 728 passed authorization information does not match the previously set 729 value, the registry MUST return an EPP error result code of 2202 730 [RFC5730]. Whether the transfer occurs immediately or is pending is 731 up to server policy. When the transfer occurs immediately, the 732 registry MUST return the EPP success result code of 1000 and when the 733 transfer is pending, the registry MUST return the EPP success result 734 code of 1001. The losing registrar MUST be informed of a successful 735 transfer request using an EPP poll message. 737 Example of passing a non-empty authorization information in an 738 [RFC5731] domain name transfer request command to authorize the 739 transfer. 741 C: 742 C: 743 C: 744 C: 745 C: 747 C: example1.com 748 C: 749 C: LuQ7Bu@w9?%+_HK3cayg$55$LSft3MPP 750 C: 751 C: 752 C: 753 C: 754 C: ABC-12345 755 C: 756 C: 758 Upon successful completion of the transfer, the registry MUST 759 automatically unset the authorization information. If the transfer 760 request is not submitted within the time-to-live (TTL) (Section 4.2) 761 or the transfer is cancelled or rejected, the registrar MUST unset 762 the authorization information as defined in Section 5.2. 764 6. Transition Considerations 766 The goal of the transition considerations to the practice defined in 767 this document, referred to as the Secure Authorization Information 768 Model, is to minimize the impact to the registrars by supporting 769 incremental steps of adoption. The transtion steps are dependent on 770 the starting point of the registry. Registries may have different 771 starting points, since some of the elements of the Secure 772 Authorization Information Model may have already been implemented. 773 The considerations assume a starting point, referred to as the 774 Classic Authorization Information Model, that have the following 775 steps in the management of the authorization information for 776 transfers: 778 1. Registrant requests to register the object with the registrar. 779 Registrar sends the create command, with a non-empty 780 authorization information, to the registry. The registry stores 781 the authorization information as an encrypted value and requires 782 a non-empty authorization information for the life of the object. 783 The registrar may store the long-lived authorization information. 785 2. At the time of transfer, Registrant requests from the losing 786 registrar the authorization information to provide to the gaining 787 registrar. 788 3. Losing registrar retrieves the stored authorization information 789 locally or queries the registry for authorization information 790 using the info command, and provides it to the registrant. If 791 the registry is queried, the authorization information is 792 decrypted and the plain text authorization information is 793 returned in the info response to the registrar. 794 4. Registrant provides the authorization information value to the 795 gaining registrar. 796 5. Gaining registrar optionally verifies the authorization 797 information with the info command to the registry, by passing the 798 authorization information in the info command to the registry. 799 6. Gaining registrar sends the transfer request with the 800 authorization information to the registry. The registry will 801 decrypt the stored authorization information to compare to the 802 passed authorization information. 803 7. If the transfer successfully completes, the authorization 804 information is not touched by the registry and may be updated by 805 the gaining registrar using the update command. If the transfer 806 is cancelled or rejected, the losing registrar may reset the 807 authorization information using the update command. 809 The gaps between the Classic Authorization Information Model and the 810 Secure Authorization Information Model include: 812 1. Registry requirement for a non-empty authorization information on 813 create and for the life of the object versus the authorization 814 information not being set on create and only being set when a 815 transfer is in process. 816 2. Registry not allowing the authorization information to be unset 817 versus supporting the authorization to be unset in the update 818 command. 819 3. Registry storing the authorization information as an encrypted 820 value versus as a hashed value. 821 4. Registry support for returning the authorization information 822 versus not returning the authorization information in the info 823 response. 824 5. Registry not touching the authorization information versus the 825 registry automatically unsetting the authorization information 826 upon a successful transfer. 827 6. Registry may validate a shorter authorization information value 828 using password complexity rules versus validating the randomness 829 of a longer authorization information value that meets the 830 required bits of entropy. 832 The transition can be handled in the three phases defined in the sub- 833 sections Section 6.1, Section 6.2, Section 6.3. 835 6.1. Transition Phase 1 - Features 837 The goal of the "Transition Phase 1 - Features" is to implement the 838 needed features in EPP so that the registrar can optionally implement 839 the Secure Authorization Information Model. The features to 840 implement are broken out by the command and responses below: 842 Create Command: Change the create command to make the authorization 843 information optional, by allowing both a non-empty value and an 844 empty value. This enables a registrar to optionally create 845 objects without an authorization information value, as defined in 846 Section 5.1. 847 Update Command: Change the update command to allow unsetting the 848 authorization information, as defined in Section 5.2. This 849 enables the registrar to optionally unset the authorization 850 information when the TTL expires or when the transfer is cancelled 851 or rejected. 852 Transfer Approve Command and Transfer Auto-Approve: Change the 853 transfer approve command and the transfer auto-approve to 854 automatically unset the authorization information. This sets the 855 default state of the object to not have the authorization 856 information set. The registrar implementing the Secure 857 Authorization Information Model will not set the authorization 858 information for an inbound transfer and the registrar implementing 859 the Classic Authorization Information Model will set the new 860 authorization information upon the successful transfer. 861 Info Response: Change the info command to not return the 862 authorization information in the info response, as defined in 863 Section 5.3. This sets up the implementation of "Transition Phase 864 2 - Storage", since the dependency in returning the authorization 865 information in the info response will be removed. This feature is 866 the only one that is not an optional change to the registrar. 867 Info Command and Transfer Request: Change the info command and the 868 transfer request to ensure that a registrar cannot get an 869 indication that the authorization information is set or not set by 870 returning the EPP error result code of 2202 when comparing a 871 passed authorization to a non-matching set authorization 872 information value or an unset value. 874 6.2. Transition Phase 2 - Storage 876 The goal of the "Transition Phase 2 - Storage" is to transition the 877 registry to use hashed authorization information instead of encrypted 878 authorization information. There is no direct impact to the 879 registrars, since the only visible indication that the authorization 880 information has been hashed is by not returning the set authorization 881 information in the info response, which is addressed in Transition 882 Phase 1 - Features (Section 6.1). There are three steps to 883 transition the authorization information storage, which includes: 885 Hash New Authorization Information Values: Change the create command 886 and the update command to hash instead of encyrpting the 887 authorization information. 888 Supporting Comparing Against Encrypted and Hashed Authorization 889 Information: 890 Change the info command and the transfer request command to be 891 able to compare a passed authorization information value with 892 either a hashed or encyrpted authorization information value. 893 Hash Existing Encrypted Authorization Information Values: Convert 894 the encrypted authorization information values stored in the 895 registry database to hashed values. The update is not a visible 896 change to the registrar. The conversion can be done over a period 897 of time depending on registry policy. 899 6.3. Transition Phase 3 - Enforcement 901 The goal of the "Transition Phase 3 - Enforcement" is to complete the 902 implementation of the "Secure Authorization Information Model", by 903 enforcing the following: 905 Disallow Authorization Information on Create Command: Change the 906 create command to not allow for the passing of a non-empty 907 authorization information value. 908 Validate the Strong Random Authorization Information: Change the 909 validation of the authorization information in the update command 910 to ensure at least 128 bits of entropy. 912 7. IANA Considerations 914 7.1. XML Namespace 916 This document uses URNs to describe XML namespaces conforming to a 917 registry mechanism described in [RFC3688]. The following URI 918 assignment is requested of IANA: 920 Registration request for the secure authorization information for 921 transfer namespace: 923 URI: urn:ietf:params:xml:ns:epp:bcp:secure-authinfo-transfer-0.1 924 Registrant Contact: IESG 925 XML: None. Namespace URIs do not represent an XML specification. 927 7.2. EPP Extension Registry 929 The EPP Best Current Practice (BCP) described in this document should 930 be registered by the IANA in the EPP Extension Registry described in 931 [RFC7451]. The details of the registration are as follows: 933 Name of Extension: "Extensible Provisioning Protocol (EPP) Secure 934 Authorization Information for Transfer" 936 Document status: Best Current Practice 938 Reference: (insert reference to RFC version of this document) 940 Registrant Name and Email Address: IESG, 942 TLDs: Any 944 IPR Disclosure: None 946 Status: Active 948 Notes: None 950 8. Implementation Status 952 Note to RFC Editor: Please remove this section and the reference to 953 RFC 7942 [RFC7942] before publication. 955 This section records the status of known implementations of the 956 protocol defined by this specification at the time of posting of this 957 Internet-Draft, and is based on a proposal described in RFC 7942 958 [RFC7942]. The description of implementations in this section is 959 intended to assist the IETF in its decision processes in progressing 960 drafts to RFCs. Please note that the listing of any individual 961 implementation here does not imply endorsement by the IETF. 962 Furthermore, no effort has been spent to verify the information 963 presented here that was supplied by IETF contributors. This is not 964 intended as, and must not be construed to be, a catalog of available 965 implementations or their features. Readers are advised to note that 966 other implementations may exist. 968 According to RFC 7942 [RFC7942], "this will allow reviewers and 969 working groups to assign due consideration to documents that have the 970 benefit of running code, which may serve as evidence of valuable 971 experimentation and feedback that have made the implemented protocols 972 more mature. It is up to the individual working groups to use this 973 information as they see fit". 975 8.1. Verisign EPP SDK 977 Organization: Verisign Inc. 979 Name: Verisign EPP SDK 981 Description: The Verisign EPP SDK includes both a full client 982 implementation and a full server stub implementation of draft-ietf- 983 regext-secure-authinfo-transfer. 985 Level of maturity: Development 987 Coverage: All aspects of the protocol are implemented. 989 Licensing: GNU Lesser General Public License 991 Contact: jgould@verisign.com 993 URL: https://www.verisign.com/en_US/channel-resources/domain- 994 registry-products/epp-sdks 996 8.2. RegistryEngine EPP Service 998 Organization: CentralNic 1000 Name: RegistryEngine EPP Service 1002 Description: Generic high-volume EPP service for gTLDs, ccTLDs and 1003 SLDs 1005 Level of maturity: Deployed in CentralNic's production environment as 1006 well as two other gTLD registry systems, and two ccTLD registry 1007 systems. 1009 Coverage: Auhtorization Information is "write only" in that the 1010 registrars can set the Auhtorization Information, but not get the 1011 Auhtorization Information in the Info Response. 1013 Licensing: Proprietary In-House software 1015 Contact: epp@centralnic.com 1017 URL: https://www.centralnic.com 1019 9. Security Considerations 1021 TBD 1023 10. Acknowledgements 1025 The authors wish to thank the following persons for their feedback 1026 and suggestions: 1028 o Michael Bauland 1029 o Martin Casanova 1030 o Scott Hollenbeck 1031 o Jody Kolker 1032 o Patrick Mevzek 1033 o Matthew Pozun 1034 o Srikanth Veeramachaneni 1036 11. References 1038 11.1. Normative References 1040 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1041 Requirement Levels", BCP 14, RFC 2119, 1042 DOI 10.17487/RFC2119, March 1997, 1043 . 1045 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 1046 DOI 10.17487/RFC3688, January 2004, 1047 . 1049 [RFC4086] Eastlake 3rd, D., Schiller, J., and S. Crocker, 1050 "Randomness Requirements for Security", BCP 106, RFC 4086, 1051 DOI 10.17487/RFC4086, June 2005, 1052 . 1054 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 1055 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 1056 . 1058 [RFC5731] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1059 Domain Name Mapping", STD 69, RFC 5731, 1060 DOI 10.17487/RFC5731, August 2009, 1061 . 1063 [RFC5733] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1064 Contact Mapping", STD 69, RFC 5733, DOI 10.17487/RFC5733, 1065 August 2009, . 1067 [RFC5734] Hollenbeck, S., "Extensible Provisioning Protocol (EPP) 1068 Transport over TCP", STD 69, RFC 5734, 1069 DOI 10.17487/RFC5734, August 2009, 1070 . 1072 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 1073 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 1074 February 2015, . 1076 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 1077 Code: The Implementation Status Section", BCP 205, 1078 RFC 7942, DOI 10.17487/RFC7942, July 2016, 1079 . 1081 [RFC8499] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS 1082 Terminology", BCP 219, RFC 8499, DOI 10.17487/RFC8499, 1083 January 2019, . 1085 11.2. URIs 1087 [1] https://csrc.nist.gov/publications/detail/fips/140/2/final 1089 Appendix A. Change History 1091 A.1. Change from 00 to 01 1093 1. Filled in the "Implementation Status" section with the inclusion 1094 of the "Verisign EPP SDK" and "RegistryEngine EPP Service" 1095 implementations. 1096 2. Made small wording corrections based on private feedback. 1097 3. Added content to the "Acknowledgements" section. 1099 A.2. Change from 01 to 02 1101 1. Revised the language used for the storage of the authorization 1102 information based on the feedback from Patrick Mevzek and Jody 1103 Kolker. 1105 A.3. Change from 02 to 03 1107 1. Updates based on the feedback from the interim REGEXT meeting 1108 held at ICANN-66: 1110 1. Section 3.3, include a reference to the hash algorithm to 1111 use. Broke the requirements into a list and included a the 1112 reference the text ', with at least a 256-bit hash function, 1113 such as SHA-256'. 1115 2. Add a Transition Considerations section to cover the 1116 transition from the classic authorization information 1117 security model in the EPP RFCs to the model defined in the 1118 document. 1119 3. Add a statement to the Introduction that elements of the 1120 practice can be used for purposes other than transfer, but 1121 with a caveat. 1122 2. Updates based on the review by Michael Bauland, that include: 1124 1. In section 2, change 'there are three actors' to 'there are 1125 three types of actors' to cover the case with transfers that 1126 has two registrar actors (losing and gaining). 1127 2. In section 3.1, change the equations equals to be 1128 approximately equal by using '=~' instead of '=', where 1129 applicable. 1130 3. In section 3.3, change 'MUST be over an encrypted channel, 1131 such as [RFC5734]'' to 'MUST be over an encrypted channel, 1132 such as defined in [RFC5734]''. 1133 4. In section 4.1, remove the optional RFC 5733 elements from 1134 the contact create, which includes the , 1135 , , , 1136 , , and elements. 1137 5. In section 4.2, changed 'Example of unsetting the 1138 authorization information explicitly in an [RFC5731] domain 1139 name update command.' to 'Example of adding the 1140 "clientTransferProhibited" status and unsetting the 1141 authorization information explicitly in an [RFC5731] domain 1142 name update command.' 1143 6. In section 4.3, cover a corner case of the ability to return 1144 the authorization information when it's passed in the info 1145 command. 1146 7. In section 4.4, change 'If the transfer does not complete 1147 within the time-to-live (TTL)' to 'If the transfer is not 1148 initiated within the time-to-live (TTL)', since the TTL is 1149 the time between setting the authorization information and 1150 when it's successfully used in a transfer request. Added the 1151 case of unsetting the authorization information when the 1152 transfer is cancelled or rejected. 1153 3. Updates based on the authorization information messages by Martin 1154 Casanova on the REGEXT mailing list, that include: 1156 1. Added section 3.4 'Authorization Information Matching' to 1157 clarify how the authorization information is matched, when 1158 there is set and unset authorization information in the 1159 database and empty and non-empty authorization information 1160 passed in the info and transfer commands. 1161 2. Added support for signaling that the authorization 1162 information is set or unset to the sponsoring registrar with 1163 the inclusion of an empty authorization information element 1164 in the response to indicate that the authorization 1165 information is set and the exclusion of the authorization 1166 information element in the response to indicate that the 1167 authorization information is unset. 1168 4. Made the capitalization of command and response references 1169 consistent by uppercasing section and item titles and lowercasing 1170 references elsewhere. 1172 A.4. Change from 03 to REGEXT 00 1174 1. Changed to regext working group draft by changing draft-gould- 1175 regext-secure-authinfo-transfer to draft-ietf-regext-secure- 1176 authinfo-transfer. 1178 A.5. Change from REGEXT 00 to REGEXT 01 1180 1. Added the "Signaling Client and Server Support" section to 1181 describe the mechanism to signal support for the BCP by the 1182 client and the server. 1183 2. Added the "IANA Considerations" section with the registration of 1184 the secure authorization for transfer XML namespace and the 1185 registration of the EPP Best Current Practice (BCP) in the EPP 1186 Extension Registry. 1188 Authors' Addresses 1190 James Gould 1191 VeriSign, Inc. 1192 12061 Bluemont Way 1193 Reston, VA 20190 1194 US 1196 Email: jgould@verisign.com 1197 URI: http://www.verisign.com 1199 Richard Wilhelm 1200 VeriSign, Inc. 1201 12061 Bluemont Way 1202 Reston, VA 20190 1203 US 1205 Email: rwilhelm@verisign.com 1206 URI: http://www.verisign.com