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

The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.

This RFC is included in the DNS RFCs annotation project whose home page is here.