[regext] FW: I-D Action: draft-ietf-regext-login-security-08.txt

"Gould, James" <jgould@verisign.com> Fri, 31 January 2020 18:06 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 33D2D120B19; Fri, 31 Jan 2020 10:06:10 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, 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 759ZdmdiJij9; Fri, 31 Jan 2020 10:06:08 -0800 (PST)
Received: from mail1.verisign.com (mail1.verisign.com [72.13.63.30]) (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 B20AF120B12; Fri, 31 Jan 2020 10:06:07 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=28315; q=dns/txt; s=VRSN; t=1580493968; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=GGz8w2CISHqWRl3QdnSGg2/H+RrbPQ6qiP8tbwpwLfs=; b=gAFmpoJRU7AXQ84qdfNzkl8JDBlbWDOqcA7RwgPpUxjJ6cgk7RqIfDV2 1MYc93GfdxXHHASb8841kPUY8r3A1nYWPqdN/9mSAItObvU1IAQzlKVFT XOa4bW7WvyoKVEjJxxN2Iv5q9qhr2n8Qc5O2jru39sDyXCvYS0M0QiU2l Fa9J2W/SpjY0fQHe0gZFSYmmlFf41IK8iymf2aXx2PUjOBraoKn8Mh6Oj kpqOgC5cPTCXHHyafeqWBieTAz5XY23n4u8b7mPQnoLqI3oka3qfSmBz4 FCsoeQIP7LRbKNxprrBC+n6KeXhwz2URzGuxvumSZCV5N4FqswUlP+b+P w==;
IronPort-SDR: 6ocRbVxgCdSrO0MsIE/zFUACUyiU9xhQDLWOBvieSD++JPl6UJth/AFQsKKt80aWV+w21pqWao Or9pfxsgqV3ROujl/FQ+9y3H+I1BzH7XjuGGXL8gSPsPbftK8iItq/k7ursJvX0lJ//NDJAC5a ESNoXAPmE0cH8ihhirmcYa3ctc46x+F5GL+Dncl7/E4sRXYyfogB3E+X1jfThjtXpZPZQWH4j7 yOfVO4ZoYUXt0bD85Sa90rL5BobM310mrvQqHzkVlR9XaDeCw5t1RQJUztvIw5HDRv5/2CWyM6 ruk=
X-IronPort-AV: E=Sophos;i="5.70,386,1574121600"; d="scan'208,217";a="642203"
IronPort-PHdr: =?us-ascii?q?9a23=3AbsPTQBX7mhaql5BiWakM7HyOK43V8LGtZVwlr6?= =?us-ascii?q?E/grcLSJyIuqrYZRCBtadThVPEFb/W9+hDw7KP9fy5BSpcud3Q4ThCKMUKC0?= =?us-ascii?q?Zez51O3kQJO42sMQXDNvnkbig3ToxpdWRO2DWFC3VTA9v0fFbIo3e/vnY4Ex?= =?us-ascii?q?T7MhdpdKyuQtaBx8u42Pqv9JLNfg5GmCSyYa9oLBWxsA7dqtQajZFtJ6osxR?= =?us-ascii?q?bFuHRFd/hZyW5sIV+YghLw6tut8JJ5/Clcpvws+9RcXanmeqgzUKBVAikhP2?= =?us-ascii?q?0p/sPgqAPNTRGI5nsSU2UWlgRHDg3Y5xzkXZn/rzX3uPNl1CaVIcP5Q7Y0WS?= =?us-ascii?q?+/76hwUx/nlD0HNz8i/27JjMF7kb9Wrwigpxx7xI7UfZ2VOf9jda7TYd8WWW?= =?us-ascii?q?xMVdtXWidcAI2zcpEPAvIBM+hGsof9u1UAoxiwBQauCuzvyyNHiXDt0KIgz+?= =?us-ascii?q?ghFBvL0BA6Et8MtnnfsdX7NL0VUeCw1KTEwzTNb/RL2Tf59YfEag0qr/WWUr?= =?us-ascii?q?J1b8XR0kcjHB7Cg1WSpozlOC6V1uAQvGWA8epvS/ivi288qwFwrTivwN0ghZ?= =?us-ascii?q?XOhoIQ013J8zhyzogyJd29UkF7YNikHYNOty6ELYt2Q9giQ2BnuCY8y70Gv4?= =?us-ascii?q?K0cDIWx5Qgwh7Tc/2HfJaU4hLtTuqRJi14hH1jdbmihBiy6VCtxvDgWsWuzV?= =?us-ascii?q?pHrCRInsPRun0N2RHf8MeKR/hl8ku8xTqDzR3f5+NYLUwuiKbWJJ0szqQtmp?= =?us-ascii?q?cQqUjDEDH5lUbqgKKTc0gr4Oul5uD8bbjjqJKQKZJ7hwD7P6s1nsGyAOY1Pw?= =?us-ascii?q?0AUmWV++mzybvu9lDjTrpQlP05iKzZvYjfJcQcu6G2HRdY0p0m6xajFzem18?= =?us-ascii?q?kYnWUfIFJFZh2Hi4/pNknTLf7kFfmznlSjni9kyf/HIrHtH4/BLmbfn7fmZ7?= =?us-ascii?q?Z981RQxxAuwtxF+ZJUEKoBIPTpVkDts9zYCwc1Mw2yw+n5FNVwzp4SVX6VDq?= =?us-ascii?q?OEMq7fv0WE6v8vLuSCfoMYtzXwJ+Ag5/H0jH85nVEdfbOu3ZsScH24HPtmI0?= =?us-ascii?q?KEYXron9gMCnkKsRQkTOzrk12CUDFTZ3CoU60g4TE7DZqqDZ3fSYC1nLyBwC?= =?us-ascii?q?C7E4VVZm9cF1+MDHToep6BW/cNdCKeONFunSEZVbK5UY8uyQmutBPmy7pgNu?= =?us-ascii?q?fU+zMXtYns1NVu5u3ciw0y9TJuA8SayWGNQHl+nnkUSD8uwKB/vUt9x0+e3q?= =?us-ascii?q?himfNYG8BT6+pIUggkKZ7cwfV2C8rsVQLOYNiIR0qmTsyiATE2QdIxwtkOb1?= =?us-ascii?q?9mG9q8kh/DwjCqA74Jl72LH5E087zT32T/J8pnzHbGzqYhhUE8QsRTLW2mmr?= =?us-ascii?q?J/9w/LCo7Lk0SWibileL8G0y7D9WeDyWuOs1tDUAJqUKXFW34fZkzOp9Tj+k?= =?us-ascii?q?zCV6OuCaggMgZZ086NNKRKZcPmjFVaX/rjOcrRY36/m2uqAhaI3LyMZpLwe2?= =?us-ascii?q?oBxCXdFFQEkwcL8HacKwc+CTmuom3CDDB3CV3vY1nj8ehkqHOgVUI0zh+Fb1?= =?us-ascii?q?Fv17av/R4Vn/OcGLsv2edOuy4ttjZcGVehmd/aFpDI8wlocLhfSdY8/BFK2X?= =?us-ascii?q?+P80Q3P5G7IIhji0IQNQNtsAmmgxR6EYpokMU2ojUt1gUkberS3ElIeS/d3J?= =?us-ascii?q?3sNPjNJ2b/7Azqb6nZ21eby9ud570O9OUQqlj/skeuDEVouyFrydBbzz6d64?= =?us-ascii?q?nESRAfXp/hTgMz8Bd7ofTBbyIg/YLIxFVtPLW69DjY1IRtTKEn2xutV95RMa?= =?us-ascii?q?eFHRS0EssUAILmfO47llWBZxwFOOFb7+g1Oc2hIb/OkrSmM+twgBqngHhJpo?= =?us-ascii?q?dn3QjEozBxRePYw74Ezu2WmAydWGG4xB27v8/6iZwBbjEbH3Ck4SnpGIAXYb?= =?us-ascii?q?d9N85fE2qhLt2rg95+jp/3QFZZ+UKtQVQc15n6VwCVagm38gpN0UhT6V6unC?= =?us-ascii?q?ajhXQgkT4us66T9DLD2eX5dRUBfGVMQT8x3h/XPYGogoVCDwCTZA8zmU796A?= =?us-ascii?q?=3D=3D?=
X-IPAS-Result: =?us-ascii?q?A2EcAwDRazRe/zCZrQpiAw4OAQEBAQEHAQERAQQEAQGBe?= =?us-ascii?q?4ElWIEYgTEKhAqQeIQTlw4XIAUJAQEBAQEBAQEBBwEYAQwKAQECgUqCL0UCF?= =?us-ascii?q?4I/OBMCAwEBCwEBAQQBAQEBAQUDAQEBAoYgDII7InkvCTkBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAggHNBkHNRIBAR4CAQMBASEKQ?= =?us-ascii?q?RsCAQguAQESAgICJQsbAQYDAgQBEoJbSwGBfYENrh2BMoQ5Ag5BhT6BOIw6g?= =?us-ascii?q?UI+gREnDBSCTD6CZAEBAgEBGIExCSQKJgECBYJBMoIsBI1Tgn+FYIJGlmgDB?= =?us-ascii?q?4I7h0WJW4U6gkh4hxWESItojmCHV2gokjECBAIEBQIVgWmBe3AVGiEqAYJBC?= =?us-ascii?q?UcYDZIQhRSFBAQBNnQKAwEki1YPFYENgRABAQ?=
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; Fri, 31 Jan 2020 13:05:40 -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; Fri, 31 Jan 2020 13:05:40 -0500
From: "Gould, James" <jgould@verisign.com>
To: "kaduk@mit.edu" <kaduk@mit.edu>, "iesg@ietf.org" <iesg@ietf.org>, "draft-ietf-regext-login-security@ietf.org" <draft-ietf-regext-login-security@ietf.org>, "jyee@afilias.info" <jyee@afilias.info>, "regext@ietf.org" <regext@ietf.org>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>
Thread-Topic: [regext] I-D Action: draft-ietf-regext-login-security-08.txt
Thread-Index: AQHV13vMvHS/RYtEbEqCwlA1sfB18agFEzmA
Date: Fri, 31 Jan 2020 18:05:40 +0000
Message-ID: <1FC24A26-ECE9-438E-9331-F8EFAFF3E917@verisign.com>
References: <C700B17F-893B-4540-B267-7FAA58BCC98F@verisign.com>
In-Reply-To: <C700B17F-893B-4540-B267-7FAA58BCC98F@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.12.200112
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_1FC24A26ECE9438E9331F8EFAFF3E917verisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/4QN8nIXprD_EuFmpYd9ebDQwNe4>
Subject: [regext] FW: I-D Action: draft-ietf-regext-login-security-08.txt
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: Fri, 31 Jan 2020 18:06:10 -0000

Benjamin,



One item that was missed in draft-ietf-regext-login-security-08 is the following item:



    I don't think this quite addresses my concern, which I will try to phrase

    more concretely: what is the expected behavior if a client that does not

    implement this extension tries to use the literal value "[LOGIN-SECURITY]"

    in a traditional <newPW> element, when the server does implement this

    extension?  If the answer is "the server accepts the new password and

    proceeds to use it for future authentication" then we get a subtle and hard

    to diagnose mess when the user moves to a different machine/implementation

    or upgrades their software; if the answer is "the server rejects the

    password as reserved", what existing part of 5730 allows the client to

    accept that?

JG2 - In the case of an invalid password, such as the sentinel value "[LOGIN-SECURITY]", or a password that does not meet the server password complexity requirements, my recommendation is for the server to return a 2200 "Authentication error" whether the client supports the Login Security Extension or not.  If the server returned a successful response, the client may assume that the new password was set, which is not the case.  If the client supports the Login Security Extension, the server can return the "newPw" security event explicitly letting the client know why the login failed.  A client that does not support the Login Security Extension would not receive the explicit reason for the error in a machine readable form.  The server can return a human-readable reason in the RFC 5730 <msg> element of the error response.  To address your concern, do you want the last sentence of section 3.2 to read:

The server MUST NOT allow the client to set the password to the value "[LOGIN-SECURITY]" by returning a 2200 "Authentication error" error.



Do you agree that the proposal addresses your concern?



Are there any other items that need to be addressed?  I can include the above and any other open items in draft-ietf-regext-login-security-09.



Thanks,



--



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 1/30/20, 9:44 AM, "Gould, James" <jgould@verisign.com> wrote:



    I posted draft-ietf-regext-login-security-08 that incorporates the feedback received during the IESG review.  Please confirm that I've addressed all of your feedback.



    Thanks,



    --



    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 1/30/20, 9:32 AM, "regext on behalf of internet-drafts@ietf.org" <regext-bounces@ietf.org on behalf of internet-drafts@ietf.org> wrote:





        A New Internet-Draft is available from the on-line Internet-Drafts directories.

        This draft is a work item of the Registration Protocols Extensions WG of the IETF.



                Title           : Login Security Extension for the Extensible Provisioning Protocol (EPP)

                Authors         : James Gould

                                  Matthew Pozun

               Filename        : draft-ietf-regext-login-security-08.txt

               Pages           : 27

               Date            : 2020-01-30



        Abstract:

           The Extensible Provisioning Protocol (EPP) includes a client

           authentication scheme that is based on a user identifier and

           password.  The structure of the password field is defined by an XML

           Schema data type that specifies minimum and maximum password length

           values, but there are no other provisions for password management

           other than changing the password.  This document describes an EPP

           extension that allows longer passwords to be created and adds

           additional security features to the EPP login command and response.





        The IETF datatracker status page for this draft is:

        https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/



        There are also htmlized versions available at:

        https://tools.ietf.org/html/draft-ietf-regext-login-security-08

        https://datatracker.ietf.org/doc/html/draft-ietf-regext-login-security-08



        A diff from the previous version is available at:

        https://www.ietf.org/rfcdiff?url2=draft-ietf-regext-login-security-08





        Please note that it may take a couple of minutes from the time of submission

        until the htmlized version and diff are available at tools.ietf.org.



        Internet-Drafts are also available by anonymous FTP at:

        ftp://ftp.ietf.org/internet-drafts/



        _______________________________________________

        regext mailing list

        regext@ietf.org

        https://www.ietf.org/mailman/listinfo/regext