Internet Engineering Task Force (IETF) Zainan (Victor) Zhou Internet-Draft Namefi zzn@namefi.io Intended status: Standards Track November 2, 2024 Expires: May 1, 2025 Domain Transfer Authorization Using Cryptographic Signatures draft-zzn-authcodesec-00 Abstract This document specifies a mechanism to enhance domain transfer security by transitioning from a shared-secret authorization model to a cryptographic signature-based validation system that enables authorization based on PKIs (Public Key Identification) and hands over control of the domain to a specific next controller identified by their PKI. The process is designed to be fully backward compatible with existing EPP systems through staged incremental upgrades. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 1, 2025. Copyright Notice Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Table of Contents 1. Status of This Memo ..................................... TBD 2. Introduction ........................................... TBD 2.1. Description of the Current Process ................ TBD 3. Protocol Elements and Mechanisms ....................... TBD 3.1. EPP Extension Overview ............................ TBD 3.2. Enhanced Authorization Information Format .......... TBD 3.3. Digest Generation ................................ TBD 3.4. Signature Generation ............................. TBD 3.5. Format in EPP Extension Element .................. TBD 3.5.1. Required Fields ........................... TBD 3.5.2. XML Schema Definition ..................... TBD 4. Verification Flow .................................... TBD 4.1. Verification Models Overview ....................... TBD 4.2. Losing Side Authorization Models ................ TBD 4.3. Gaining Side Authorization Models ................ TBD 5. Security Considerations ............................... TBD 6. Draft Notes: Unresolved Feedbacks and Design Questions. TBD 6.1. Threat Analysis ................................. TBD 6.1.6.1. Cross-Registrant Misuse ................ TBD 6.1.6.2. Double-Selling Protection ............... TBD 6.1.6.3. Audit Trail Limitations ................ TBD 6.2. Choosing between pwAuthInfo and extAuthInfo ...... TBD 7. References ........................................... TBD 7.1. RFCs ........................................... TBD 7.2. Other Documents ................................. TBD 1. Status of This Memo (TODO: add status of this memo) 2. Introduction This document specifies a mechanism to enhance domain transfer security by transitioning from a shared-secret authorization model to a cryptographic signature-based validation system that enable authorization based on PKIs (Public Key Identification) and hand over the control of the domain to specific next controller identified by their PKI. The process is designed to be fully backward compatible with existing EPP systems with staged incremental upgrades inspired by the DNSSEC, HTTPS, and Credit Card Chip migration. The current transfer process relies on the presentation of an authentication code (authcode) by the gaining registrar as proof of transfer authority. This specification defines an extended authorization information format that incorporates cryptographic signatures, enabling registries to validate multiple aspects of the transfer request: * that it originates from the legitimate domain registrant * that it contains the correct receiving registrant information * that it includes proper approval signature or signatures from designated parties when required (such as administrative contacts or other stakeholders) To ensure smooth transition and maintain interoperability with existing systems, this specification includes backward compatibility mechanisms allowing registries and registrars to support both the legacy authcode format and the new signature-based format simultaneously. The specification provides guidance for gradual migration while maintaining existing transfer workflows, enabling deployments without requiring synchronized updates across all participants in the domain registration ecosystem. 2.1 Description of the Current Process The current EPP transfer request process defined in RFC-5730 involves the following sequence: 2.1.1. The losing registrar sets or updates the authInfo for a domain object through an EPP command to the registry. The registry MUST store this authInfo value in its database. 2.1.2. The losing registrar provides this authInfo code to the current registrant. The method of this transmission is out of scope of the EPP protocol. 2.1.3. The current registrant provides this authInfo code to the gaining registrar. This transmission method is also out of scope of the EPP protocol. 2.1.4. The gaining registrar submits a transfer request to the registry through EPP command, which MUST include this authInfo in the request. 2.1.5. The registry MUST validate that the provided authInfo matches the one stored in the registry database for this domain. 2.1.6. Upon successful validation, the registry MUST notify both registrars, update the domain object status to "pendingTransfer", and MUST change the authInfo to a new value known only to the registry. This validation mechanism relies solely on the matching of a shared secret between parties, which presents several security limitations that this specification aims to address. The fact that the authInfo must be transmitted between multiple parties out-of-band increases the risk of compromise. 2.2. Threat Model The extension intends to address the following advanced security issues in the context of authInfo-based domain transfer mechanism: * Man-in-the-Middle Attacks during out-of-band transmission * Insider Threats from registrar employees and support staff * Lack of Transfer Intent Binding * Revocation Management Issues * Replay Attacks, including: - No temporal validity constraints - Multiple use vulnerability - Lack of transfer context binding - Missing nonce protection * Cross-Registrant Vulnerabilities: - AuthInfo leakage and reuse - Double-selling risks - Insufficient audit trails 2.3. Extensibility Assumptions This specification builds upon several extensibility aspects of RFC-5730 (EPP): 2.3.1. AuthInfo Structure Extensibility According to RFC-5730 Section 2.7.1, EPP provides an extension framework that allows for definition of both new protocol operations and object extensions: * The element MUST contain up to one instance of any object extension elements * Any object extension element MAY extend any object element, including the element * Extension elements MUST be qualified by a XML namespace declaration This extensibility mechanism allows for the enhancement of the authInfo structure while maintaining backward compatibility. 2.3.2. Password Element Size After reviewing RFC-5730, it's worth noting that the specification does not explicitly define size limitations for the domain:pw element. In current practice most authcodes are 6-8 characters long. but transitioning to a signature-based system will require a longer authcode. 2.3.3. Verification Assumptions The following verification behavior is defined in RFC-5730 Section 2.9.3.4: * The server MUST validate the authorization information provided when a command is processed * The server MAY reject requests that contain authorization information that has aged beyond a server-specific date or time This existing verification requirement provides the foundation for extending the validation process to include cryptographic signature verification. 2.3.4. Implementation Considerations Given the extensibility mechanisms provided by RFC-5730 and the lack of explicit size constraints: * This specification MUST use proper XML namespace declarations for all new elements * New elements MUST be added within the framework * Implementations MUST maintain compatibility with existing authInfo processing * Size limitations MUST be specified for all new elements * The extension SHOULD allow for future cryptographic algorithm updates 3. Protocol Description This section defines the protocol elements and mechanisms for the new cryptographic signature-based domain transfer authorization system. 3.1. EPP Extension Overview The protocol leverages EPP extensions to convey the enhanced authorization information, including the authorization information, cryptographic digest, and associated signatures. These extensions augment existing EPP transfer request operations. 3.2. Enhanced Authorization Information Format The enhanced authorization information format includes: * The approver's PKI * The approver's authority type: registrant, registrar (and it can be extended to allow other types of authorities such as law enforcement or judicial bodies) * Anti-replay protection mechanisms (e.g., expiration timestamp, nonce) * Additional authorization parameters The authorization information is encoded in XML format as an EPP extension element. 3.3. Digest Generation The protocol defines standardized steps and methods for generating cryptographic digests from the authorization information. This includes: * Specification of supported hash algorithms * Canonicalization of input data * Digest computation procedure 3.4. Signature Generation The protocol specifies the process for generating cryptographic signatures, including: * Supported signature algorithms * Key requirements and formats * Signature computation procedure using the registrant's key 3.5 Format in EPP Extension Element The enhanced authorization information is encoded in XML format as an EPP extension element as followed: 3.5.1 Required Fields The enhanced authorization information consists of the following required fields: * version - Schema version number * domainName - The domain name being transferred * nonce - Incremental number to prevent replay attacks * receiverInfo - Container for receiver details: * receiverType: Type of receiving entity (registrant/registrar) * receiverKey: PKI of the receiver * receiverIdentifier: Unique identifier of the receiver * approverInfo - Container for approver details: * approverType: Type of approving entity (registrant/registrar) * approverKey: PKI of the approver * approverIdentifier: Unique identifier of the approver * digestInfo - Container for digest details: * digestAlgorithm: Hash algorithm used * digestValue: Hexadecimal representation of the computed digest 3.5.2 XML Schema Definition BEGIN Extension to EPP extAuthInfoType for secure domain transfers ... TODO add other types of authorities such as ... TODO: add supported algorithms / standard to define digesting END 3.5.3. Signature in domain:pw The signature value in domain:pw is the Base64-encoded value of the signature computed over the digest: C: C: Base64EncodedSignatureValueComputedOverTheDigest ... C: 3.5.4 Example Usage Example of a domain transfer request with enhanced authorization information: C: C: C: C: C: C: example.com C: C: Base64EncodedSignatureValueComputedOverTheDigest ... C: C: C: C: C: C: 1.0 C: example.com C: f7027456abc8903d C: C: registrant C: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBC... C: C: RECV-12345 C: C: C: registrant C: MIIBIjANBgkqhkiG9w0BAQEFAAOCAQ8AMIIBC... C: C: APPR-67890 C: C: C: sha256 C: 2CF24DBA5FB0A30E73043362938B9824... C: C: C: C: C: ABC-12345 C: C: 4. Verification Flow The protocol specifies the process for verifying cryptographic signatures, including: * Signature verification procedure using the registrant's key * Verification of anti-replay protection mechanisms * Verification of additional authorization parameters This specification defines three models of transfer verification to ensure smooth transition from traditional authInfo to the new cryptographic signature-based system. 4.1. Verification Models Overview The verification process consists of two components: the losing side authorization and the gaining side verification. Each component can operate in one of three models, allowing for staged migration: +----------------+------------------------------------------+ | Model | Description | +----------------+------------------------------------------+ | Model A | Full cryptographic model with registrant | | | signatures and keys | | Model B | Semi-cryptographic model with registrar | | | signatures and keys | | Model C | Traditional authInfo model | +----------------+------------------------------------------+ The three models are designed to allow for staged migration from the current authInfo-based mechanism to the new cryptographic signature-based mechanism. Model A is the strongest and most secure model, but also requires the most significant changes to existing workflows. Model C is the weakest and least secure model, but also requires the least changes to existing workflows. Any party, registrant, registrar or registry can start by supporting Model C and then move to Model B or Model A as needed. Any party can add their support for Model A or Model B at any time, when transfer counter party doesn't support the same model, the transfer can still be completed by falling back to a lower model, as described in section 4.4. 4.2. Model A. Full Cryptographic Model 4.2.1 Request to update the PKI * Any current registrant can request its current registrar to update its registrant information with the enhanced authorization information including the PKI. * If such the current registrant already is registered with a PKI, such request MUST include a crypography signature to prove the ownership of the PKI and apporval of the update request. Otherwise, the registrar MUST validate the authenticity of the (TODO: define the update flow and EPP command) * And then the current registrar MUST submit a transfer request to the registry with the enhanced authorization information to trigger the transfer process. Assuming the registry supports Model A, the transfer request MUST be rejected if the enhanced authorization information is missing, the signature is invalid, or the PKI is not updated. (TODO: define the error codes and error messages) 4.2.2. Request to update the AuthInfo (optional) This step can be skipped if all parties in the transfer chain support Model A. But for backward compatibility, the current authInfo-based mechanism can be used as a fallback. The current registrant can authorize a transfer of domain by signing the enhanced authorization information demonstrated in section 3.5.4. by cryptographic signing with its PKI. (TODO: define an example of payload to be signed and digesting algorithm) The signature value denoted as `sig` will be placed in the domain:pw element as defined in section 3.5.3. The current registrant will then submit a transfer request to the registrar, and the registrar will submit a transfer request to the registry. The registry will verify the signature of the current registrant using the PKI and the enhanced authorization information, and it will save the signature value in the registry database for future reference. 4.2.3. The gaining registrar will submit a transfer request to the registry Supposedly the gaining registrar supports Model A, the gaining registrant (it could be the same as the current registrant or someone who bought the domain from the current registrant) will submit a transfer request to the registry with the enhanced authorization information. The gaining registrar will first verify the signature of the gaining registrant using the PKI and the enhanced authorization information, and then it will submit a transfer request to the registry with the enhanced authorization information. The registry will verify the signature of the gaining registrant using the PKI and the enhanced authorization information, if the signature is valid, the registry will complete the transfer process by updating the domain new owner to the gaining registrant, including the PKI. (TODO: define example EPP command, and define the error codes and error messages) 4.3. Fallback based on support of PKI If the registry doesn't support PKI, the transfer process will fallback to Model C. Else if any of the registrars doesn't support PKI, the transfer process will fallback to Model C. Else if both registrars support PKI, the transfer process will fallback to Model B. But even if registry doesn't support PKI, if both registrars support PKI, the authcode can be verified using PKI which is stronger than merely Model C. This incremental upgrade mechanism enables each individual registrar to benefit from adding the PKI support without waiting for the other registrar to add support, similar to the approach of DNSSEC, HTTPS deployment and bank credit card chips rollout. 5. Security Considerations TODO: limitation due to lack of finalization of decentralized ledgers. 6. Draft Notes 6.1. Description of Threat Model The RFC aims at addressing the following advanced threat models: 6.1.1. Man-in-the-Middle Attacks Since the authInfo transmission between registrant and registrars occurs out-of-band and often through insecure channels (e.g., email, control panel screenshots, support tickets): * The authInfo can be intercepted during transmission * There is no cryptographic binding between the authInfo and the intended receiving registrant * A malicious actor can initiate an unauthorized transfer using an intercepted authInfo 6.1.2. Insider Threats The shared-secret nature of authInfo creates vulnerabilities to insider threats: * Any employee at the losing registrar with access to the control panel can view or extract authInfo values * Support staff handling customer requests can potentially misuse authInfo codes they've accessed * There is no cryptographic proof that the actual domain registrant initiated or approved the transfer 6.1.3. No Binding to Transfer Intent The authInfo serves only as a shared secret without any binding to: * The identity of the intended receiving registrant * The intended timing of the transfer * Additional authorization requirements (e.g., corporate domain transfers requiring multiple approvals) * The specific transfer request itself, allowing replay attacks 6.1.4. Revocation Challenges Once an authInfo has been compromised: * There is no standardized mechanism to revoke it without performing a domain update * The registrant may not realize the compromise until after an unauthorized transfer occurs * The registry cannot distinguish between legitimate and unauthorized uses of a valid authInfo 6.1.5. Replay Attacks The current authInfo-based mechanism lacks several essential protections against replay attacks: 6.1.5.1. Temporal Validity * The authInfo has no built-in expiration mechanism * Once generated, it remains valid until explicitly changed * A captured authInfo can be used at any future time until the losing registrar or registrant updates it * There is no standard way to limit the validity period of an authInfo 6.1.5.2. Multiple Use * The same authInfo can be used multiple times for different transfer attempts * A malicious actor can: - Capture a valid authInfo during a legitimate transfer - Store it for future unauthorized transfers - Use it again after the domain returns to the original registrar * The registry cannot distinguish between the original intended use and subsequent replay attempts 6.1.5.3. Transfer Context * The authInfo is not bound to any specific transfer context * The same code can be used to initiate transfers: - To different gaining registrars - At different times - With different receiving registrant details * There is no cryptographic binding between the authInfo and the intended transfer parameters 6.1.5.4. No Nonce Protection * The protocol lacks a nonce or similar mechanism to ensure uniqueness of each transfer request * Transfer requests cannot be uniquely identified or tracked * Makes it impossible to implement replay detection at the protocol level 6.1.6. Cross-Registrant Vulnerabilities within Same Registrar The current authInfo mechanism lacks isolation between different registrants at the same registrar: 6.1.6.1. Leaked AuthInfo Reuse * A registrar employee or system with access to multiple registrants' authInfo could: - Extract authInfo from one registrant's domain - Use it for transfers of another registrant's domain * The registry cannot detect this cross-registrant misuse as the authInfo format and validation is identical * No cryptographic binding exists between the authInfo and the specific registrant identity 6.1.6.2. Double-Selling Protection * A malicious registrar could: - Generate valid authInfo for the same domain - Provide them to different potential buyers - Allow multiple transfer attempts using different authInfo * The current mechanism cannot prevent or detect: - Multiple valid authInfo existing simultaneously - Which registrant was the legitimate intended transferee - Whether the authInfo was generated with proper authorization 6.1.6.3. Audit Trail Limitations * No cryptographic proof of: - Which registrant authorized the authInfo generation - When the authorization was granted - The intended receiving registrant * Makes dispute resolution difficult in cases of: - Unauthorized cross-registrant transfers - Double-selling incidents - Employee misconduct 6.2. Unresolved Quesiton: How to choose between pwAuthInfo and extAuthInfo? Scott says in > Having said that, I designed EPP in a way that allows for > specification of other approaches. Section 4.2 of RFC 5730 includes > the schema that defines authorization information. Note the > "pwAuthInfoType" and the "extAuthInfoType" type definitions. > "extAuthInfoType" can be used as a "hook" to define a new type. > Given that the capability exists, I'd suggest that you send a note > to the IETF REGEXT working group mailing list asking if anyone is > interested in the possibility of defining an extension for a new > PKI-based authorization information type. You'd be better of > measuring people's interest in the topic before you invest a lot of > time working on a proposal. > -- S. Hollenbeck, 2024-03-19 https://mailarchive.ietf.org/arch/msg/regext/pRSTKwvDRM4WM_s-nme2PRig4Z4/ In practice it domain:ext has not been widely used. And since we want to maintain backward compatibility with existing systems. The author of this document propose that we should choose pwAuthInfo over extAuthInfo for better backward compatibility. 7. References 7.1. RFCs * RFC 1034 by P. Mockapetris * RFC 1035 by P. Mockapetris * RFC 5730 by S. Hollenbeck * RFC 5731 by S. Hollenbeck * RFC 5732 by S. Hollenbeck * RFC 7451 by S. Hollenbeck * RFC 7848 by G. Lozano * RFC 8334 by J. Gould, W. Tan, G. Brown * RFC 8807 by J. Gould, M. Pozun * RFC 9095 by J. Yao, L. Zhou, H. Li, N. Kong, J. Xie * RFC 9154 by J. Gould, R. Wilhelm * draft-ietf-regext-verificationcode-06 by J. Gould, R. Wilhelm, 7.2. Other Documents - Presentation: Transfer Authcodes at .se and .nu by Eric Skoglund (Apr 2024) - Discussion: [\[regext\]Fwd: Idea about AuthCodeSEC: use PKI Cryptography for AuthCode] (https://mailarchive.ietf.org/arch/msg/regext/WPNywS9VAFhE3sJTRn9cR7FcRA4/) (TODO: add other documents) Author's Address Zainan (Victor) Zhou Namefi Email: zzn@namefi.io