Return-Path: X-Original-To: regext@ietfa.amsl.com Delivered-To: regext@ietfa.amsl.com Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id ED87F12006B for ; Thu, 19 Dec 2019 23:53:41 -0800 (PST) X-Virus-Scanned: amavisd-new at amsl.com X-Spam-Flag: NO X-Spam-Score: -1.898 X-Spam-Level: X-Spam-Status: No, score=-1.898 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, HTML_MESSAGE=0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id THRqtqk2_zvs for ; Thu, 19 Dec 2019 23:53:38 -0800 (PST) Received: from mailg210.ethz.ch (mailg210.ethz.ch [IPv6:2001:67c:10ec:5606::21]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 52539120041 for ; Thu, 19 Dec 2019 23:53:37 -0800 (PST) Received: from mailm115.d.ethz.ch (2001:67c:10ec:5602::27) by mailg210.ethz.ch (2001:67c:10ec:5606::21) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Fri, 20 Dec 2019 08:53:31 +0100 Received: from mailm212.d.ethz.ch (2001:67c:10ec:5603::26) by mailm115.d.ethz.ch (2001:67c:10ec:5602::27) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1847.3; Fri, 20 Dec 2019 08:53:35 +0100 Received: from mailm212.d.ethz.ch ([fe80::f8f6:45ef:96ed:eee]) by mailm212.d.ethz.ch ([fe80::f8f6:45ef:96ed:eee%3]) with mapi id 15.01.1847.005; Fri, 20 Dec 2019 08:53:35 +0100 From: Martin Casanova To: "Hollenbeck, Scott" , "regext@ietf.org" Thread-Topic: [regext] How to handle Domain Info Command with empty authinfo/pw tag in command? Thread-Index: AQHVtktRIxUkdgVjgkuFl4P8CT96kqfBUSqAgAFTVfU= Date: Fri, 20 Dec 2019 07:53:35 +0000 Message-ID: References: , In-Reply-To: Accept-Language: de-CH, en-US Content-Language: de-CH X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [212.51.156.80] x-tm-snts-smtp: 647BD3A377668E86DEC5772BDC5904970661D1B6FD14F9FC90395BE8173768082000:8 Content-Type: multipart/alternative; boundary="_000_dcfde32c48f245da9695435dfd18d056switchch_" MIME-Version: 1.0 Archived-At: Subject: Re: [regext] How to handle Domain Info Command with empty authinfo/pw tag in command? X-BeenThere: regext@ietf.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: Registration Protocols Extensions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 20 Dec 2019 07:53:42 -0000 --_000_dcfde32c48f245da9695435dfd18d056switchch_ Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable 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 informatio= n 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 Gesendet: Donnerstag, 19. Dezember 2019 13:24:29 An: Martin Casanova; regext@ietf.org Betreff: RE: [regext] How to handle Domain Info Command with empty authinfo= /pw tag in command? Martin, you also have to consider client identification and authorization w= hen trying to determine an appropriate response code. I can see returning r= esult code 1000 to a sponsoring registrar who omits the authInfo, but a req= uest from a non-sponsoring registrar who omits the authInfo should produce = a 2201 response code. A 2202 would make sense for a non-sponsoring registra= r who provides invalid authInfo. Scott > -----Original Message----- > From: regext On Behalf Of Martin Casanova > Sent: Thursday, December 19, 2019 4:04 AM > To: regext@ietf.org > Subject: [EXTERNAL] [regext] How to handle Domain Info Command with > empty authinfo/pw tag in command? > > 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 associated with the domain object. > > RFC-5731 about : ... 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 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 () 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 is set or not even without knowing it. > After all, the registry could have set or deleted without noti= cing > the registrar. However many clients seem to send > just about always and they would need to > adjust. > > I have to mention that our Domain Info response will never include the ac= tual > since we only store a hash of it for security reasons. > A Domain Info Command with the 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 martin.casanova@switch.ch, www.switch.ch > > Working for a better digital world > > > _______________________________________________ > regext mailing list > regext@ietf.org > https://www.ietf.org/mailman/listinfo/regext --_000_dcfde32c48f245da9695435dfd18d056switchch_ Content-Type: text/html; charset="us-ascii" Content-Transfer-Encoding: quoted-printable

Scott, thank you for your feedback. I investigated why we are not return= ing 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 informa= tion 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 sp= onsoring client and/or sending the correct authinfo/pwd)


Martin

Von: Hollenbeck, Scott &l= t;shollenbeck@verisign.com>
Gesendet: Donnerstag, 19. Dezember 2019 13:24:29
An: Martin Casanova; regext@ietf.org
Betreff: RE: [regext] How to handle Domain Info Command with empty a= uthinfo/pw tag in command?
 
Martin, you also have to consider client identific= ation and authorization when trying to determine an appropriate response co= de. I can see returning result code 1000 to a sponsoring registrar who omit= s the authInfo, but a request from a non-sponsoring registrar who omits the authInfo should produce a 2201 re= sponse code. A 2202 would make sense for a non-sponsoring registrar who pro= vides invalid authInfo.

Scott

> -----Original Message-----
> From: regext <regext-bounces@ietf.org> On Behalf Of Martin Casan= ova
> Sent: Thursday, December 19, 2019 4:04 AM
> To: regext@ietf.org
> Subject: [EXTERNAL] [regext] How to handle Domain Info Command with > empty authinfo/pw tag in command?
>
> 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 n= ot 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 co= rrect (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/></authinf= o>) we are
> wondering if:
> Option 1: always Response Code 1000 should be returned Option 2: Only<= br> > 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<= br> > authorization information delivered.
>
>
> I think maybe option 2 may be better because that way a registrar coul= d
> check if an <authinfo> is set or not even without knowing it. > After all, the registry could have set or deleted <authinfo> wit= hout noticing
> the registrar. However many clients seem to send
> <authinfo><pw/></authinfo> just about always and the= y 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 omitt= ed 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 martin.casanova@switch.ch, www.switch.ch
>
> Working for a better digital world
>
>
> _______________________________________________
> regext mailing list
> regext@ietf.org
> https://www.i= etf.org/mailman/listinfo/regext
 --_000_dcfde32c48f245da9695435dfd18d056switchch_--