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

[Eric Skoglund <[e-mail]>]

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 <[e-mail]> on behalf of Zainan Victor Zhou <[e-mail]>
Sent: 24 March 2024 20:21
To: [e-mail] <[e-mail]>
Cc: [e-mail] <[e-mail]>; [e-mail] <[e-mail]>
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
[e-mail]<mailto:[e-mail]> (work) / [e-mail]<mailto:[e-mail]> (personal)

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