Hi Victor. We at .se and .nu recently changed our authcode implementation and for that we did have a look around to see what other registries were doing. I don't think we came across anyone looking at a PKI-based approach and to second what Scott said such an approach would probably find it hard to get any traction.
Here is a talk we did at ICANN78 giving some information about the needs we and some other registries have regarding the authcodes, perhaps giving some idea on why that would be: https://github.com/johanix/iis-talks/blob/main/erics/icann78-authcodes/talk.pdf // Eric The Swedish Internet Foundation ________________________________ From: regext <regext-boun...@ietf.org> on behalf of Zainan Victor Zhou <z...@zzn.im> Sent: 24 March 2024 20:21 To: regext@ietf.org <regext@ietf.org> Cc: shollenb...@verisign.com <shollenb...@verisign.com>; z...@namefi.io <z...@namefi.io> Subject: [regext] Fwd: Idea about AuthCodeSEC: use Public Key Cryptography for AuthCode Scott, that's very helpful, thank you! Yes I notice that EPP (RFC 5730) was intentionally extendable. It's very helpful that you point to me that Section 4.2 lays the schema that defines authorization information. I will look into how to leverage existing pwAuthInfoType and extAuthInfoType. Let me send this email to REGEXT -- Victor (Resending with my email that I use for IETF) ------------ Hi dear REGEXT wg, TL;DR: are there existing efforts to bring public key authentication to EPP that leverage RFC 5730's extendability? Is this working group the best place to start the conversation about existing effort? The closest related effort in IETF I could found was - EPPEXT working group that was concluded in 2016 https://datatracker.ietf.org/wg/eppext/about/ - RFC 9154 Extensible Provisioning Protocol (EPP) Secure Authorization Information for Transfer https://datatracker.ietf.org/doc/rfc9154/ which uses a short lived cryptographic hash If there are existing standards, I love to learn more and put that into our implementation. If there were no existing effort, here is an early draft https://github.com/xinbenlv/rfc-draft-authcodesec/blob/main/README.md<https://secure-web.cisco.com/1c4kGADnaAssbpJjX636xmm3ye_X_zd1TnA94M3YM94OTCNk6NPOw_NbQWbKSx0qaTeauV0Th34kXvu8sQhjV_Fnkyp085fdbaDiwLG2IVaR-xJY6srk4dUGcmtdIEOpdjrUVydgMCIKiyDh1w0-jQIMtpEXc7V29R9aWtCo-CO0aiE94MeTepkvMd-nH81xF0hGHLT3C_2QZ82gdIJ62392-fXa38wA8XEMrU9b2w8VS5gP5eZ4Aj2hnCn87UTQclWoyv1zoOCRFkYFdVZtL4QjLxLNC1oDuLWu-S47Yu3xfJH1sQpHzN0cYdjg-PAJi/https%3A%2F%2Fgithub.com%2Fxinbenlv%2Frfc-draft-authcodesec%2Fblob%2Fmain%2FREADME.md> and I would love to see if anyone is interested in participate in future discussion of a possible RFC and maybe co-author? Victor Zhou z...@namefi.io<mailto:z...@namefi.io> (work) / z...@zzn.im<mailto:z...@zzn.im> (personal) On Sun, Mar 17, 2024 at 3:58 PM Hollenbeck, Scott <shollenb...@verisign.com<mailto:shollenb...@verisign.com>> wrote: Thank for the note, Victor. I’m not aware of anyone who has extended EPP’s authorization information data structures, though the ability to do so has always been available. Note this text from Section 2.9.3.4 of RFC 5730: “The type of authorization information required is object-specific; passwords or more complex mechanisms based on public key cryptography are typical.” We defined a password-based authorization information approach for domain objects because it was felt to be sufficient and secure as long as other protocols were used to protect the data while in transit. EPP requires TLS, for example, so the authorization information is never exchanged without encryption protection. In practice, passwords are NOT received from end-users/registrants and stored; they’re more commonly generated on-demand as a result of a domain transfer request. They’re short-lived and the risk of exposure is actually quite low. I haven’t heard of any issues associated with compromised authorization information being used to request a fraudulent transfer. If you’re aware of any documented “AuthCode stealing or disputes” I’d be interested in hearing about them. I’m not confident that the domain industry would be interested in implementing and operating a PKI-based approach given that the password approach has been working reliably for more than 20 years. There would need to be a significant value proposition for registries and registrars to switch. 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. I hope this helps, Scott From: Victor Zhou <z...@namefi.io<mailto:z...@namefi.io>> Sent: Friday, March 15, 2024 6:42 PM To: Hollenbeck, Scott <shollenb...@verisign.com<mailto:shollenb...@verisign.com>> Subject: [EXTERNAL] Idea about AuthCodeSEC: use Public Key Cryptography for AuthCode Caution: This email originated from outside the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe. Hi Mr. Hollenbeck, My name is Victor and I found you as the main author of EPP including RFC 5730 and many RFCs. Really appreciate your contribution! (I may have run into you in the last IETF 117 event in San Francisco happy hour but unsure) I like to ask you a question regarding AuthCode: in the EPP RFC 5730 you wrote Objects eligible for transfer MUST have associated authorization information that MUST be provided to complete a <transfer> command. The type of authorization information required is object-specific; passwords or more complex mechanisms based on public key cryptography are typical. In my personal experience, most of AuthCode was a plaintext secret. I have not seen any public key cryptography. Are you aware of any one who uses public key cryptography and if there is a standard? I ask because if there is no effort in this direction, I like to start the conversation with you and the proper IETF working group about proposing an RFC that standardize a publickey cryptography transfer that allows independent validation and backward compatibility (to current AuthCode) and future compatibility (for smart contact validation). Here is a early early draft https://github.com/xinbenlv/rfc-draft-authcodesec/blob/main/README.md<https://secure-web.cisco.com/1c4kGADnaAssbpJjX636xmm3ye_X_zd1TnA94M3YM94OTCNk6NPOw_NbQWbKSx0qaTeauV0Th34kXvu8sQhjV_Fnkyp085fdbaDiwLG2IVaR-xJY6srk4dUGcmtdIEOpdjrUVydgMCIKiyDh1w0-jQIMtpEXc7V29R9aWtCo-CO0aiE94MeTepkvMd-nH81xF0hGHLT3C_2QZ82gdIJ62392-fXa38wA8XEMrU9b2w8VS5gP5eZ4Aj2hnCn87UTQclWoyv1zoOCRFkYFdVZtL4QjLxLNC1oDuLWu-S47Yu3xfJH1sQpHzN0cYdjg-PAJi/https%3A%2F%2Fgithub.com%2Fxinbenlv%2Frfc-draft-authcodesec%2Fblob%2Fmain%2FREADME.md> Or to save you a click: here is the full text snapshot --------------------------- # RFC-draft-AuthCodeSEC ## Summary Today, the main way domain names transfer between users or registrars is using a mechanism called "AuthCode". This RFC proposes an upgrade to the current AuthCode, leveraging public key cryptography, including a schema of payload signing designed to be fully backward compatible with the existing AuthCode in EPP (RFC 5730) while leaving room for future extensions. This RFC also explores a 4-phased incremental approach to replace AuthCode. ## Background AuthCode was introduced in EPP (RFC 5730), in which it says: ``` Objects eligible for transfer MUST have associated authorization information that MUST be provided to complete a <transfer> command. The type of authorization information required is object-specific; passwords or more complex mechanisms based on public key cryptography are typical. ``` In practice, public key cryptography is rarely used in today's EPP practices. Instead, a plaintext secret string is being used. For example, one of the most used EPP software is provided by CentralNic, called "RSP". It uses a plaintext string as the AuthCode. The AuthCode is stored in the database of the registrar, and when a user wants to transfer a domain, the user logs in to the registrar's website to get the AuthCode, and then gives it to the gaining registrar. The gaining registrar then sends the AuthCode to the TLD registry, and the TLD registry then sends the AuthCode to the losing registrar (via message queue, poll, or other ways). The losing registrar then validates the AuthCode and then releases the domain to the gaining registrar. TODO: add workflow diagram Here is a common use case: a registrant wants to hand over a domain to another registrant. For the sake of discussion, let's call the losing registrant Larry and the gaining registrant George, and Larry uses a registrar called "Lovely Registrar", and the registrar George uses is called "Great Registrar". The problem with this process is that the AuthCode is a plaintext string: - Its validation is only via Lovely Registrar matching the string with its own knowledge; no one other than Lovely Registrar could validate it. Not any party of the transaction, Larry or George, Great Registrar or TLD Registry, nor anyone else. - It assumes the whole transmission of AuthCode, across multiple parties, is without leaking or eavesdropping. - In many cases today, such AuthCodes are not being updated for a long time or never expire, leaving the system even more vulnerable to leaks or eavesdropping. Neither RFC 5730 nor any follow-up RFC specified a way to force reset AuthCode. Due to these issues, the internet domain name system suffers from AuthCode stealing or disputes. ## Specification ### Overview We hereby propose the following mechanism: - Use public key cryptography to use an authentication signature as AuthCode. - We suggest the default algorithm as `secp256r1`, but it can support other signing algorithms or accept multiple signatures or aggregate signatures. - We suggest the schema to be signed as the payload being the `EPP object` in the EPP communication, and a normalization scheme. - We suggest including expiration time and nonce. We suggest a deny- list approach for early rejection. ### Details TODO: add schema of payload to sign TODO: add a way to establish or update public keys, such as depend on DNSSEC. TODO: add how the payload is represented in EPP object TODO: add how to validate the signature using the public key ## Discussion ### Backward Compatibility The main design goal is to allow the upgrade to be done incrementally at each registrar without breaking the existing workflow. For example, assuming in a transaction of a transfer of domain, the losing registrar has already upgraded to the new mechanism, instead of storing the AuthCode in the database and comparing it, it can validate the AuthCode directly itself. And if the gaining registrar has not been upgraded to be aware of this new spec, they won't be able to validate the AuthCode on the spot, but as long as they collect the AuthCode, they can still process the AuthCode in the same manner. ### Forward Compatibility The main forward design compatibility is in the event a distributed public ledger is involved, such as a smart contract is being used. They can be configured to validate the signature of this transfer and update the holdings of the account automatically without trusting a third party to vouch for the transfer. TODO: add sample code to validate the signature in the Solidity language ## Naming The way to introduce AuthCode is similar to how DNSSEC was rolled out without breaking DNS, hence we call it AuthCodeSEC. ### Roadmap Inspired by how banks' payment networks rolled out chips, we imagine there can be a 4-phase rollout to support this proposal, such as each phase to be 3-5 years: - Phase 1: Registrars who implement the AuthCode can provide benefits of instant validation and validation by anyone without connection. - Phase 2: When the losing registrar implements it, it reduces the cost to pay for insurance or dispute to half. The other side shares half of the dispute cost. - Phase 3: When the losing registrar implemented it, it is excused from paying for the dispute, the gaining side pays, and users are getting a warning. - Phase 4: Without implementing AuthCodeSEC jeopardizes breaking the workflow or user experience of its users.
_______________________________________________ regext mailing list regext@ietf.org https://www.ietf.org/mailman/listinfo/regext
