[regext] FW: 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