Re: [regext] Idea about AuthCodeSEC: use Public Key Cryptography for AuthCode

[Victor Zhou <[e-mail]>]

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

------------

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
[e-mail] (work) / [e-mail] (personal)

On Sun, Mar 17, 2024 at 3:58 PM Hollenbeck, Scott <[e-mail]>
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 <[e-mail]>
> *Sent:* Friday, March 15, 2024 6:42 PM
> *To:* Hollenbeck, Scott <[e-mail]>
> *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.
>
>