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

[Martin Casanova <[e-mail]>]

Hello

Thank you all for the feedback!

As Jim and Patrick pointed out an empty XML tag should be interpreted as
"empty string" value rather than as not defined "[null] value".
This makes it easy for us: We can simply always return 2202 for an empty
tag since our server policy would not allow such an empty string
authinfo/pwd to be set in the first place. (our min. length requirement
is 6 characters)

I like the suggestion of Jim to include an empty authinfo element in the
response to indicate that the authinfo is set and no authinfo element if
the authinfo is not set -
provided that the client is authorized for the domain meaning being the
sponsoring client or providing the correct authinfo/pwd in the request.

(The same authorized logic we use to determine whether or not to return
the <domain:exDate>  in the domain info response.)


Martin


On 20.12.19 15:50, Gould, James wrote:
>
> Martin,
>
>  
>
> My feedback is embedded below.
>
>  
>
> -- 
>
>  
>
> JG
>
>
> cid:[e-mail]933A30
>
> *James Gould
> *Distinguished Engineer
> [e-mail]
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>  
>
> *From: *regext <[e-mail]> on behalf of Martin Casanova
> <[e-mail]>
> *Date: *Friday, December 20, 2019 at 3:51 AM
> *To: *"[e-mail]" <[e-mail]>
> *Subject: *[EXTERNAL] Re: [regext] How to handle Domain Info Command
> with empty authinfo/pw tag in command?
>
>  
>
> 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.
>
>  
>
> JG – No, I’m not arguing that an empty auth info in the command (info
> or transfer request) should be considered a match with a null auth
> info value in the info or transfer commands, since that would be a
> dangerous security hole.  I agree that the result of passing an empty
> authinfo in the info or transfer commands should result in the 2202
> error result.  I’ll take a closer look at
> draft-gould-regext-secure-authinfo-transfer to ensure that it clearly
> defines an unset authinfo as not being a match with the passing of an
> empty authinfo value in the info or transfer commands.  An unset
> authinfo should be set to null and not set to a hashed empty string. 
>
>  
>
>  
>
> 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)
>
>  
>
> JG – For the sponsoring registrar, you could return an empty authinfo
> in the response to indicate that the authinfo is set and return no
> authinfo element if the authinfo is not set.  There would be no need
> for the sponsoring registrar to pass the authinfo element.  This could
> also be covered in draft-gould-regext-secure-authinfo-transfer, since
> draft-gould-regext-secure-authinfo-transfer currently states that the
> info response MUST NOT include the optional authinfo element.  I don’t
> believe there is an issue providing an indication of whether the
> authinfo is set or not set with the sponsoring registrar.  The concern
> was providing the indication to the non-sponsoring registrars. 
> Thoughts on taking this approach to address the use case?   
>
>  
>
> 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 <[e-mail]> im Auftrag von Gould, James
> <jgould=[e-mail]>
> *Gesendet:* Donnerstag, 19. Dezember 2019 14:39:08
> *An:* Martin Casanova; [e-mail]
> *Betreff:* Re: [regext] How to handle Domain Info Command with empty
> authinfo/pw tag in command?
>
>  
>
> 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
> [e-mail]
> <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[e-mail]>
>
> 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"
> <[e-mail] on behalf of [e-mail]> wrote:
>
>     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 [phone], direct [phone]
>     [e-mail], www.switch.ch <http://www.switch.ch>
>     
>     Working for a better digital world
>    
>    
>     _______________________________________________
>     regext mailing list
>     [e-mail]
>     https://www.ietf.org/mailman/listinfo/regext
>    
>
> _______________________________________________
> regext mailing list
> [e-mail]
> https://www.ietf.org/mailman/listinfo/regext
>
-- 
--- 
SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone [phone], direct [phone]
[e-mail], www.switch.ch 
 
Working for a better digital world