Subject: [regext] How to handle Domain Info Command with empty authinfo/pw tag in command?

From: Martin Casanova <[email-masked]>
Date: Thu, 19 Dec 2019 10:04:28 +0100

Hello

I was hoping for some input of the community about an implementation
decision for the Domain Info Command/Response when it comes to the
optional <domain:authInfo> associated with the domain object.

RFC-5731 about  <domain:authInfo>: ... If this element is not provided
or if the authorization information is invalid, server policy
 determines if the command is rejected or if response information will
be returned to the client.

1.
In case the <authinfo><pw> element is delivered but not correct (no
match or not set on domain) we will return a Code 2202 to inform.
(sponsoring client or not)

2.
In case an empty tag is given (<authinfo><pw/></authinfo>) we are
wondering if:
Option 1: always Response Code 1000 should be returned
Option 2: Only answer with 1000 when there is NO authinfo/pw set on the
domain (kind of confirming it) and otherwise 2202 considering an empty
tag as invalid authorization information delivered.

I think maybe option 2 may be better because that way a registrar could
check if an <authinfo> is set or not even without knowing it.
After all, the registry could have set or deleted <authinfo> without
noticing the registrar. However many clients seem to send
<authinfo><pw/></authinfo> just about always and they would need to adjust.

I have to mention that our Domain Info response will never include the
actual <authinfo> since we only store a hash of it for security reasons.
A Domain Info Command with the <authinfo> Element entirely omitted will
always be answered with 1000.

Thanks and merry X-Mas!

Martin Casanova

--- 
SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone +41 44 268 15 55, direct +41 44 268 16 25
[email-masked], www.switch.ch 
 
Working for a better digital world

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Thu, 19 Dec 2019 12:24:29 +0000

Martin, you also have to consider client identification and authorization when trying to determine an appropriate response code. I can see returning result code 1000 to a sponsoring registrar who omits the authInfo, but a request from a non-sponsoring registrar who omits the authInfo should produce a 2201 response code. A 2202 would make sense for a non-sponsoring registrar who provides invalid authInfo.

Scott

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Martin Casanova
> Sent: Thursday, December 19, 2019 4:04 AM
> To: [email-masked]
> Subject: [EXTERNAL] [regext] How to handle Domain Info Command with
> empty authinfo/pw tag in command?
>
> Hello
>
> RFC-5731 about  <domain:authInfo>: ... If this element is not provided or if
> the authorization information is invalid, server policy
>  determines if the command is rejected or if response information will be
> returned to the client.
>
> 1.
> In case the <authinfo><pw> element is delivered but not correct (no match
> or not set on domain) we will return a Code 2202 to inform.
> Option 1: always Response Code 1000 should be returned Option 2: Only
> answer with 1000 when there is NO authinfo/pw set on the domain (kind of
> confirming it) and otherwise 2202 considering an empty tag as invalid
> authorization information delivered.
>
>
> After all, the registry could have set or deleted <authinfo> without noticing
> the registrar. However many clients seem to send
> I have to mention that our Domain Info response will never include the actual
> <authinfo> since we only store a hash of it for security reasons.
> Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland phone +41 44 268 15 55,
> direct +41 44 268 16 25 [email-masked], www.switch.ch
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext

---

From: "Gould, James" <[email-masked]>
Date: Thu, 19 Dec 2019 13:39:08 +0000

Martin,

I believe option 2 in case 2 is the best approach, but I don't believe an empty auth info should match a non-set auth info value.  Per the practice defined in draft-gould-regext-secure-authinfo-transfer, unsetting the auth info should result in a null auth info and not a hashed empty string that would then match a subsequent empty auth info value.  I view both cases as being the same case of an invalid auth info resulting in a 2202 error response.

-- 
 
JG

James Gould
Distinguished Engineer
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/>

On 12/19/19, 4:04 AM, "regext on behalf of Martin Casanova" <[email-masked] on behalf of [email-masked]> wrote:

    Hello

    
    1.
    
    2.

    
    Thanks and merry X-Mas!
    
    Martin Casanova
    
    --- 
    SWITCH

---

From: Martin Casanova <[email-masked]>
Date: Fri, 20 Dec 2019 07:53:35 +0000

Scott, thank you for your feedback. I investigated why we are not returning 2201 to non-sponsoring clients and have been told that at the time when we started with EPP, it was decided that we would deliver the same information to a non-sponsoring client as is available over the WHOIS protocol...

The only difference that we make today is to exclude the expiration date of the domain if not not authorized. (authorized being the sponsoring client and/or sending the correct authinfo/pwd)

Martin

________________________________
Von: Hollenbeck, Scott <[email-masked]>
Gesendet: Donnerstag, 19. Dezember 2019 13:24:29
An: Martin Casanova; [email-masked]
Betreff: RE: [regext] How to handle Domain Info Command with empty authinfo/pw tag in command?

Scott

> direct +41 44 268 16 25 [email-masked], www.switch.ch<http://www.switch.ch>
>

---

From: Martin Casanova <[email-masked]>
Date: Fri, 20 Dec 2019 08:50:58 +0000

Jim

Thanks you for the feedback.

I agree that hashing an empty String to match a not set authinfo is not the way to go. We are using [null] values in the db for a not set authinfo field.  However I think you could argue that semantically and empty XML tag is somewhat similar to a not filled db field being [null] and therefore consider it "matching". But since an empty string is not a valid authinfo according to server policy's length and complexity requirements 2202 is certainly justified.

However this runs into the same situation as option 1 returning always 1000 where there is no way for the sponsoring client to query if authinfo is set on the domain at all. (without having to check for correctness)

It is a constructed example but you could imagine a domain with status serverUpdateProhibited and authinfo set/removed by the registry. Then the client could not simply reset the authinfo nor query if it is set or not. Of course we would send a ChangePoll enriched Poll Msg to the sponsoring registrar if we do that... :)

Probably it is enough to be able to verify correctness of an authinfo e.g. before a transfer..

Martin

________________________________
Von: regext <[email-masked]> im Auftrag von Gould, James <jgould=[email-masked]>
Gesendet: Donnerstag, 19. Dezember 2019 14:39:08
An: Martin Casanova; [email-masked]
Betreff: Re: [regext] How to handle Domain Info Command with empty authinfo/pw tag in command?

Martin,

--

JG

James Gould
Distinguished Engineer

703-948-3271
12061 Bluemont Way
Reston, VA 20190

    Hello

    1.

    2.

    Thanks and merry X-Mas!

    Martin Casanova

    ---
    SWITCH
    Martin Casanova, Domain Applications
    Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
    phone +41 44 268 15 55, direct +41 44 268 16 25
    [email-masked], www.switch.ch<http://www.switch.ch>

---

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 20 Dec 2019 04:06:06 -0500

On Fri, Dec 20, 2019, at 03:50, Martin Casanova wrote:
> I agree that hashing an empty String to match a not set authinfo is not 
> the way to go. We are using [null] values in the db for a not set 
> authinfo field. However I think you could argue that semantically and 
> empty XML tag is somewhat similar to a not filled db field being [null] 

I strongly disagree.
It is the same thing as the difference in an RDBMS when you store "" (the empty string)
or NULL (the undefined value). Those are two different things, and for good reason.

<pw/> or <pw></pw> means an empty password, the empty string.
No XML pw node means an undefined password, as the data is just not there, so unknown.

Like said in other threads, this all shows to me that efforts should be put
into finding now new ways to operate, without domain passwords as they became
useless, instead of trying to fix with various warts the current situation.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 20 Dec 2019 04:28:09 -0500

> optional <domain:authInfo> associated with the domain object.

Unfortunately, currently, everyone does things differently.
I recently made an internal survey about how registries reply in the following
cases of domain:info

- by sponsor (note that I seem to recall a registry giving out an error
if you are sponsor but do provide the authInfo, where without it is a success)
- when not sponsor, without an authInfo, with a valid one, with an invalid one
- and also for an unregistered domain, results with or without authInfo.

I still need to be able to wrap my brains around the multiple cases I have found,
no uniformity at all. This makes life of registrars very complicated,
but the problem here comes from the special handling of passwords, and also
GDPR-level issues.

> tag as invalid authorization information delivered.

Like said in other message, a node being there but empty means the empty value
not the undefined one. I would say the reply should be positive only if the
domain authInfo is also the empty string (which is different from being undefined)
 
> noticing the registrar.

Registries should at least send EPP notifications for anything they do on 
registrar objects, otherwise registrars have no hope to keep their own
database in sync.

> However many clients seem to send

There are as many broken clients as they are broken servers...
 
-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Fri, 20 Dec 2019 16:47:36 +0000

Patrick,

The EPP RFC 5731 does support the explicit <domain:null> element to remove the authorization information, so there is an explicit mechanism available in the RFC to set the authorization information to NULL (the undefined value).  For example, the following can be used to delete the authorization information:

...

   C:        <domain:chg>

   C:          <domain:authInfo>

   C:            <domain:null/>

   C:          </domain:authInfo>

   C:        </domain:chg>

...

Where there is no explicit element in the EPP RFCs to indicate not setting or unsetting the authorization information, the empty authorization information can be used for this purpose in a defined practice, such as draft-gould-regext-secure-authinfo-transfer.  We need to ensure that the empty authorization information never matches the unset authorization information to protect the authorization of actions such as returning the full info response or executing a transfer request.

Having discussion and agreement around the authorization information practice would help with the inconsistencies that you outlined in your follow-on message, and help increase the authorization information security.

--

JG

James Gould

Distinguished Engineer

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 12/20/19, 4:06 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    I strongly disagree.

    --

      Patrick Mevzek

      [email-masked]

    regext mailing list

    [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 20 Dec 2019 12:13:45 -0500

On Fri, Dec 20, 2019, at 11:47, Gould, James wrote:
> The EPP RFC 5731 does support the explicit <domain:null> element to 
> remove the authorization information, so there is an explicit mechanism 
> available in the RFC to set the authorization information to NULL (the 
> undefined value).

Yes, I know, and this exactly outlines why an absent node is not the same
thing as a node with an empty value.

Said differently,
<domain:authInfo><domain:pw/></domain:authInfo> is an existing authInfo whose
value is the empty string
where
<domain:authInfo><domain:null/></domain:authInfo> means an undefined authInfo
(so could be any value).

> Where there is no explicit element in the EPP RFCs to indicate not 
> setting or unsetting the authorization information, the empty 
> authorization information can be used for this purpose in a defined 
> practice, such as draft-gould-regext-secure-authinfo-transfer. 

As you know, I am not convinced this is the best course for the future,
nor that it really fits the working group. But that is just me.

> Having discussion and agreement around the authorization information 
> practice would help with the inconsistencies that you outlined in your 
> follow-on message, and help increase the authorization information 
> security. 

I remain in another side: other solutions, instead of passwords, should be found.
Continuing to use passwords when other (better) solutions exist is not an effort
I find useful.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 20 Dec 2019 18:04:17 +0000

> From: regext <[email-masked]> On Behalf Of Patrick Mevzek
> Sent: Friday, December 20, 2019 12:14 PM
> To: [email-masked]
> Subject: [EXTERNAL] Re: [regext] How to handle Domain Info Command with

[snip]

> I remain in another side: other solutions, instead of passwords, should be

I designed the authInfo concept to be extensible because I also thought that passwords would have a limited lifetime. Patrick, if you have some other ideas, why not toss them out for discussion?

Scott