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

"Gould, James" <jgould@verisign.com> Thu, 06 February 2020 21:42 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 5B5E012080F; Thu, 6 Feb 2020 13:42:26 -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 pSRmqqWpTuz3; Thu, 6 Feb 2020 13:42:23 -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 82A21120812; Thu, 6 Feb 2020 13:42:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=44332; q=dns/txt; s=VRSN; t=1581025343; h=from:to:subject:date:message-id:references:in-reply-to: mime-version; bh=Mc8kKVqaPZ+bAR0FMHBRpD5uAIH5eriHIlPfvn6CUVM=; b=LjOx0PwoZETHnL8hlhaJfL6yj+UiXShGedrlacfkxyT/gN9H5nlBCBND ek/ggp6j4nBiH22Jodv0+Z/Xhz/PLu6++5BuUd8pQ+hoj6b7C7VGyA8cP bX0iaitEyH55VrzgHNpjCGzC7e6nES08rscIhTvO+YMKPf3jqijhfRWOe v+Je+c+XWhZ58jG21UYtTJFNHttzLJhnSSp4q5JeJDmn/DYo+IxFfsF8u W0MUW0r24d1tYz8cqzFN1oHn9Os0wdS5Bj1aj+bwCAWKLh0HXq/ferluv 0QuQyhF1rCBp7K/C++Z+zpHCrI/+sI6SeA8QO2g5tmfmrQbUTn0R7Y5/i w==;
IronPort-SDR: wnApIsFOF1rVLAKKnAEHSHpM1Bk72ZwpkGLhMxJIlOXb5CKeri6VkPn8BV3ym1IybJ+/7ULHpC a80TJAyGlJUYeu5+8nfbYWTA5XJsxJCNGv0fxVjJdqoiZcWXABJiocQyorSpFzYNWtjDuhlA60 wb+Qtiy3pPJ4D1DyiLHrXTdxTPog8myEd5/sAtmlP2/dsG4khw9cSXzA5DawuQ0ssM3f7wLVFM wUy+eYwa2GrdR/Q/XTrWbW7qfS3q7GUtw2Eo+brUPd1u+i6JCeNwfAbAARxMoq4Xn4qXsai0tu rkU=
X-IronPort-AV: E=Sophos;i="5.70,411,1574121600"; d="png'150?scan'150,208,217,150";a="101594"
IronPort-PHdr: =?us-ascii?q?9a23=3AaswgHx2AEaH2LNbmsmDT+DRfVm0co7zxezQtwd?= =?us-ascii?q?8ZsesSLf3xwZ3uMQTl6Ol3ixeRBMOHsq4C1rGd6v24ESxYuNDd6StEKMQNHz?= =?us-ascii?q?Y+yuwu1zQ6B8CEDUCpZNXLVAcdWPp4aVl+4nugOlJUEsutL3fbo3m18CJAUk?= =?us-ascii?q?6nbVk9Kev6AJPdgNqq3O6u5ZLTfx9IhD2gar9uMRm6twrcutQZjId4Kqs8xB?= =?us-ascii?q?TFrmZIduhK2GhkIU6fkwvm6sq/4ZJu/T5ct+49+8JFTK73Y7k2QbtEATo8Lm?= =?us-ascii?q?s7/tfrtR7NTQuO4nsTTGAbmQdWDgbG8R/3QI7/vjP1ueRh1iaaO9b2Ta0vVj?= =?us-ascii?q?S586hrUh7ohzwZODM/7Wral9Z/jKNfoBKmuhx/34vZa5ybOfZiYq/Qe84RSG?= =?us-ascii?q?xcVchTSiNBGJuxYYsRAeQcIeZWoYrzp1UMohSwBAmjGOzgxyRShnPq2K03yf?= =?us-ascii?q?gtHBvE0QEmAtkAsG7UrNLwNKoKX+y7za7IzSjHb/xLwTv29YzGfQokof6SRr?= =?us-ascii?q?J8f9faxE4tFwPKiVWQtIjlMC6O2+QTrWeb9etgVfmui24orQF9uCSgxsApio?= =?us-ascii?q?TQgI8e117K9SJ8wIkvJN24TlZ2YcC6H5tKtiGaLIp2QswkQ2FpviY11qcKto?= =?us-ascii?q?K8fCgP0JgnxgDQa+CJc4SS5RLjTumRLDFlj3xmYLKynwu+/VS6xuHhVMS53k?= =?us-ascii?q?xGojdFn9TCrHwA2B/e5tCaRvdh5EutxDSC2xzJ5u1ZLk05lrDXJ4Miz7IomJ?= =?us-ascii?q?ocr0fOEjPzlUjzlqCbdUEp9fOt5unpfLnpu56ROopvhQz6M6kjmMmyDOo2Pw?= =?us-ascii?q?UMQmeW//m32qf58k3jWrpKi+U7kqzesJ/HO8sWvrW5AwpJ0oY77Ba/Eium3M?= =?us-ascii?q?wYnXYZKFJFfwqKgpX1NV/WPfz3De+xjVutnzt32vzKJKPhDYnKLnjZiLftZ6?= =?us-ascii?q?xy5FNGxAot19Bf/JRUBqsdL/L0X0/9rN3YDhknPAyo2+vrFclx2pkDVW+NDK?= =?us-ascii?q?KVKr7evF+G6+41LOSBZ5cZuDPnJPgk4/7ug2U5mVgYfaSx35sXZ3e4HuliI0?= =?us-ascii?q?qEenfsnMkOEX0LvgolTezqh1uCXSRPaHa1WqIw/is7B56+DYffWoCth6SM3C?= =?us-ascii?q?ShEZJLe2BGCUuBEXLpd4WYQfsDdj+dItJ5mDweSbehU5Mh1Q2ptALiyrpoMP?= =?us-ascii?q?HU+iIDuJLiytd1++PTmQs19TxuAMSXy3uNQH1snmMUWz8227hyrlFnyliZ36?= =?us-ascii?q?h4n+VUFd1N6PNVXAc2LITcwPJ1C9/sVQPBYs6FSFKhQtWpADExSMs9w8QQbE?= =?us-ascii?q?lhBtWilBHD3zaqArIOlryEGoA08qzG03j2PcZ9xG7M1LM9gFk+XstPKWqmi7?= =?us-ascii?q?Z99wnTGYHGjV6UmLykdaQd2C7N9X2MzXGUsEFZVg5wX6LFV2gFZkTKtdT5+l?= =?us-ascii?q?/CT7i2BLQ9LARBxtCNK6RWatDyjFVJWuvjONrEb2K2gWewCg6CxqmQY4ryZ2?= =?us-ascii?q?UdwCLdBVAekw8N8naJKwc/Bju4r23CDDxhD1PvY1n38eRlqXO0UFM0zw+QY0?= =?us-ascii?q?1mzbq19U1dufvJAfAa0q8HkCIgt3N5EEv3l4bVAtadpCJkfbkabN8gthMPn2?= =?us-ascii?q?PUrANVP5G8IeZlnFFUO1B2sljh/xR6FosGltIl+jdihgZoIKyElVJMaz3dx5?= =?us-ascii?q?3/N63Lb2318xGpLrXb0UzE0cqH0qYC9Pp+rE/s9kn9GlAr/Wki0tRJ3T6G65?= =?us-ascii?q?rHHBZXVZX+U0By7BVxuqvbfjgV5o7I2ztrK6bi9neI2cMkCcMsxBekft5Edq?= =?us-ascii?q?KCGgi4W5kYFsWjAOUkmlyoZwlCPeZc8/hwd4m8evSLyLKDPet8knShl2sNqN?= =?us-ascii?q?Rn302B5zZUS+PU0dAC2f7OmkPNTTrzgUe998v3kIFefhkTE3axjy/+C8QZMr?= =?us-ascii?q?d/cosbFSKlI8S23M5WhpPxVThf7lH1VH0c38r8MzWVcljxmUVy3EEaujbvzS?= =?us-ascii?q?m3yCFwnxk3o7Cexy3BxaLpcx9RaT0Df3VrkVq5edv8tNsdRkX9NwU=3D?=
X-IPAS-Result: =?us-ascii?q?A2GyBAB7hzxe/zCZrQpjAw4OAQEBAQEHAQERAQQEAQGBe?= =?us-ascii?q?4ElWIEYgTEKhAuRAyWDD1+XERcdAwEEAgcBAQEBAQEBAQEDAQMBGAEMCgEBA?= =?us-ascii?q?oFKgi9FAheCSzgTAgMBAQsBAQEEAQEBAQEFAwEBAQKGIAyCOyJ5Lwk5AQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBBQIIBzQZBzUSAQEdA?= =?us-ascii?q?QEBAQMBAQMBHQIIAUAbAgEIEQMBAgYBAQEOAQEIAQkCAgIFEAEOAQsdCAIEA?= =?us-ascii?q?REBBgiCTUsBgwqtFXWBMoQ1AQMCDkGFUBCBOIMKhCSFD4FCPoERJwwUgkw+g?= =?us-ascii?q?mQBAQIBARiBMQkmCQEmAQIFgkEygiwEjViCf4VigRKBNYxegm6HHwMHgjqGJ?= =?us-ascii?q?gKBIolchTuCSHiHGIRIi2uNJ4E7h1toKZI3AgQCBAUCFYFpgXtwFRohKgGCQ?= =?us-ascii?q?QlHGA2OKReDUIUUhQQEATZ0CgMBJItXDxWBDYEQAQE?=
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, 6 Feb 2020 16:42:00 -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, 6 Feb 2020 16:42:00 -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/RYtEbEqCwlA1sfB18agFEzmAgAmqaYA=
Date: Thu, 6 Feb 2020 21:42:00 +0000
Message-ID: <A014A351-3D12-4444-8124-30ABEEA99383@verisign.com>
References: <C700B17F-893B-4540-B267-7FAA58BCC98F@verisign.com> <1FC24A26-ECE9-438E-9331-F8EFAFF3E917@verisign.com>
In-Reply-To: <1FC24A26-ECE9-438E-9331-F8EFAFF3E917@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.12.200112
x-originating-ip: [10.170.148.18]
Content-Type: multipart/related; boundary="_004_A014A3513D124444812430ABEEA99383verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/D2bcDfFtI5vYzlOEO_RebaWlGiI>
Subject: Re: [regext] 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: Thu, 06 Feb 2020 21:42:27 -0000

Benjamin,

I believe that all of your Discuss items have been addressed (e.g., discussed and change incorporated where applicable), except for the open issue sent in the prior message below.   Do you agree with the proposed change, which can be addressed in draft-ietf-regext-login-security-09?  If you agree that your Discuss items have been addressed, can you clear your Discuss ballot position?

Thanks,

--

JG

[cid:image001.png@01D255E2.EB933A30]

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/>

From: James Gould <jgould@verisign.com>
Date: Friday, January 31, 2020 at 1:06 PM
To: "kaduk@mit.edu" <kaduk@mit.edu>du>, "iesg@ietf.org" <iesg@ietf.org>rg>, "draft-ietf-regext-login-security@ietf.org" <draft-ietf-regext-login-security@ietf.org>rg>, Joseph Yee <jyee@afilias.info>fo>, "regext@ietf.org" <regext@ietf.org>rg>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>
Subject: FW: [regext] I-D Action: draft-ietf-regext-login-security-08.txt


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