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

"Gould, James" <jgould@verisign.com> Thu, 19 December 2019 13:39 UTC

Return-Path: <jgould@verisign.com>
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 13305120133 for <regext@ietfa.amsl.com>; Thu, 19 Dec 2019 05:39:17 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
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 jyVZhW6tV72q for <regext@ietfa.amsl.com>; Thu, 19 Dec 2019 05:39:13 -0800 (PST)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (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 CD4B512029C for <regext@ietf.org>; Thu, 19 Dec 2019 05:39:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=4180; q=dns/txt; s=VRSN; t=1576762754; h=from:to:date:message-id:references:in-reply-to: content-id:content-transfer-encoding:mime-version:subject; bh=nIZLlESpNd3DdZVtHyUtwXW4jVo/t5v0jVw8eLbnMo0=; b=W+pO5olHawPt3AHT1l7gV6PNNC2UNl9s/5xj2e6uyEE3qq+pNmCuSeuB uiHS1014ICfVKShtwC/CfdNh0eRGLDc/cN35Uey+1d+2xtAiJpDANb5vN vSvP1Z+0xlPytb0mdvObhu8NAnHB457YbmrdVJTjttLGYkt81qrWCTPZN zsrLzTB8DHijZNqz3tJ7UkI55RulBZrbAvYPsxMPIa35rKKEowqg4wonJ FS9XLp3550wlA1WjiijABRJiev3Ouk4DsFFk4Ln68qLfFvmcrTc+qQwNe R9/xSNrsV1UKwdlYL/AXVKf18mUg70+y3eCp5rG0kcWubOgdlCIRuzHBh A==;
IronPort-SDR: ayzjLKAlei9e4beemxQY41Sh24C/NdQsHWVW5nm5Rwgzoe+MJwN4HdZyp4KZiL/GGtryQTTSRi a5ErceO7MmO8YVRddkde8rFYk+Cbhy59dFy+iFiaUnoZ/MTCcsiS6ANVfdaNspSN8stBdSGn/e E1ZZCTolldSpJ5gsEQumGd2MmC13XjtYq7Z4PLR3qDRaqM45nDp2Or6ZAnXShM0wDZa5fQ6cRl ubTgWGrD/lHOvulA2jspny67Hvr7FgkDQaKtSUkRTMzhHREBGvD5kjy7Uz8HcQDkMyAUGpZO2v TSE=
X-IronPort-AV: E=Sophos;i="5.69,332,1571702400"; d="scan'208";a="21599"
IronPort-PHdr: =?us-ascii?q?9a23=3Anrd70R/BBpUAe/9uRHKM819IXTAuvvDOBiVQ1K?= =?us-ascii?q?B+0+0WIJqq85mqBkHD//Il1AaPAdyAragd0qGL6OjJYi8p2d65qncMcZhBBV?= =?us-ascii?q?cuqP49uEgeOvODElDxN/XwbiY3T4xoXV5h+GynYwAOQJ6tL1LdrWev4jEMBx?= =?us-ascii?q?7xKRR6JvjvGo7Vks+7y/2+94fcbglVijexe61+IAiroQnetsQbj5ZpJ7osxB?= =?us-ascii?q?fOvnZGYfldy3lyJVKUkRb858Ow84Bm/i9Npf8v9NNOXLvjcaggQrNWEDopM2?= =?us-ascii?q?Yu5M32rhbDVheA5mEdUmoNjBVFBRXO4QzgUZfwtiv6sfd92DWfMMbrQ704RS?= =?us-ascii?q?iu4qF2QxLzliwJKyA2/33WisxojaJUvhShpwBkw4XJZI2ZLedycr/Bcd8fQ2?= =?us-ascii?q?dKQ8RfWDFbAo6kb4UBEfcPPfpWoYf+qVsBrxWxBQiwC+3gxTBFnWP20rY/0+?= =?us-ascii?q?g9DQ3Lxg4tEtQTu3rUttX1M6ISXPi7wKfJyjXDcvdW1irl5IPVdh4uu/SMUq?= =?us-ascii?q?xrccbf1EIiEAHFjlqXqYz4OzOay/8As3aF4Op6VOKvkG8nqw53ojS12sgsjY?= =?us-ascii?q?zJi5sTx1vZ+yt5x4M1Kse5SE59edOkDoVftzubN4ttQ8MiTGdouCc8yrIao5?= =?us-ascii?q?K0YC8KyJE/yx7EZf2HcpSI7Q7jVOqLPTh4hGppeLOhiBau/0is0Or8VtO70F?= =?us-ascii?q?tMsyFLkcHMu2gQ2xDP8MSLV/lw80m71TqS1w3e5PtILE83mKbDNpIt3qQ8mo?= =?us-ascii?q?cRvEjfBCP6hUr7gayMekk5+eWk8+rnbavlq5OAMoJ5jxvxP6cql8OkBOk1PB?= =?us-ascii?q?YCUHWa9Om5z7Lu+Uz0TbdPg/A4nKTUso3VKMIGraCjGQBVyJws6xOnAjej19?= =?us-ascii?q?QXgGcIIUpeeBKCk4jpI1bOIO3kDfung1SjjjNrx/feM7D8HpvDNmXPn7f5c7?= =?us-ascii?q?hy6kFQ1Bc/wcpB551IDbEBOurzVlXru9PFFBM5LRa0w/3hCNlnyoweXmePDr?= =?us-ascii?q?eYMKPUr1CI+voiL/SQaIMPpTrwKfYo6+TzgXI5l1IRZ6ak0JgPZHC9BPtmIk?= =?us-ascii?q?GZYXT2gtcGFGcHpgg+TOPtiF2fVT5cem2/X7wi6TEhCYKmFobDRo+rgLCbwC?= =?us-ascii?q?i7GZhWanhcCl+QCXfoa5mEW/AUZSKXOMBhiCAEVbmnS4M7yR6hrhT6xKBhLu?= =?us-ascii?q?rT5C0Xr4nu1MN75u3SiRE96Tx0A96B3GGNV2t0hH8HRycq3KBjpkxw0k2D3r?= =?us-ascii?q?Z3g/NGGt1T++hEUgYkOp7Awex2EdfyWhjOfoTBdFHzZ9y8HTA3Bvk42NYIZF?= =?us-ascii?q?h0U4Gnhwrf3izsCLYOnrqMGpUc6b3dw3PxYc19nTKOnrMsgFQ2XuNOOHGowK?= =?us-ascii?q?ll+EKbU5TEnEiJi46reLgSminX+zHQ43CJuRQSfwltVamBFVIWY0bN55yt5E?= =?us-ascii?q?zFUruiIaoqKApayMGEbKBNb4u63h19WP7/NYGGMCqKkGCqCEPNn+vUYQ=3D?= =?us-ascii?q?=3D?=
X-IPAS-Result: =?us-ascii?q?A2GPBAAVfftd/zCZrQphAx0BAQEJAREFBQGBfAKDDIExC?= =?us-ascii?q?oN8lQiXCBcbCgkBAQEBAQEBAQEHARgLDAEBAoN5RQIXgio4EwIDAQELAQEBB?= =?us-ascii?q?AEBAQEBBQMBAQEChiAMQgEQAYFnKQFbDi8JATgBAQEBAQEBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEFAggFAjQZBQI1EgEBHgIBAwEBIREVJRkCA?= =?us-ascii?q?gEIGgImAgICGQwLFRACBAEJCRSDDgGDBqxkgTKKQQWBCSgBhRyHFoFCPoE4I?= =?us-ascii?q?IFOUC4+gmQBAYFNLQomgkkygiwEjT4qgkuIGZY/AweCNIZMZoFZjSiCQ3WXG?= =?us-ascii?q?Y5Rh0djKJF/AgQCBAUCFYFpgXtwFTsqAYJBCUcYDY0dGBWDEyiFFIU/dA0kg?= =?us-ascii?q?m2MaDFfAQE?=
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1779.2; Thu, 19 Dec 2019 08:39:08 -0500
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1779.002; Thu, 19 Dec 2019 08:39:08 -0500
From: "Gould, James" <jgould@verisign.com>
To: Martin Casanova <martin.casanova@switch.ch>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] [regext] How to handle Domain Info Command with empty authinfo/pw tag in command?
Thread-Index: AQHVtktY0LWF5xug6UyznM8N6epXa6fBdssA
Date: Thu, 19 Dec 2019 13:39:08 +0000
Message-ID: <35BAECA0-9B4A-4C1F-9EEF-BA9C4BE2E325@verisign.com>
References: <d17d88d0-e9db-9416-1917-dc992fcd2d3a@switch.ch>
In-Reply-To: <d17d88d0-e9db-9416-1917-dc992fcd2d3a@switch.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.f.191014
x-originating-ip: [10.170.148.18]
Content-Type: text/plain; charset="utf-8"
Content-ID: <F3D851926F38534BB694CCA8A8CFF474@verisign.com>
Content-Transfer-Encoding: base64
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/EhZipgDDyD_7EGpreZIThlmqr4c>
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 <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 19 Dec 2019 13:39:17 -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
jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>

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" <regext-bounces@ietf.org on behalf of martin.casanova@switch.ch> 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 +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