Re: [regext] review of draft-ietf-regext-login-security-03

Patrick,

The password expression can be included in the error response using the human readable message per registry policy, which will work for troubleshooting purposes only, since the human readable message should not be parsed by the client.  The login security extension is not well suited for communicating policy information, which is the point of draft-gould-regext-login-security-policy.  The password policy information can be formally communicated via draft-gould-regext-login-security-policy over EPP or using an out-of-band mechanism.        

Supporting other forms of authentication is best handled via a separate extension of EPP (e.g., protocol extension).  The purpose of draft-ietf-regext-login-security is primarily to address the password length limitation in EPP RFC 5730. 

—

JG

James Gould
Distinguished Engineer
jgould@Verisign.com

703-948-3271
12061 Bluemont Way
Reston, VA 20190

Verisign.com <http://verisigninc.com/> 

On 4/9/19, 1:50 PM, "regext on behalf of Patrick Mevzek" <regext-bounces@ietf.org on behalf of pm@dotandco.com> wrote:

    On Tue, Mar 26, 2019, at 12:56, Martin Casanova wrote:
    > I know that you have foreseen draft-gould-regext-login-security-policy 
    > to query about password complexity but I think for convenience of the 
    > registrar it would still be nice to somehow include the password 
    > requirement in the response even if it is redundant. Otherwise one has 
    > to implement draft-gould-regext-login-security-policy at the same time 
    > or communicate the requirement out of band.
    > 
    >  maybe like that
    > 
    >    S:        <loginSec:event
    >    S:          type="newPW"
    >    S:          value="expression: 
    > (?=.*\d)(?=.*[a-zA-Z])(?=.*[\x21-\x2F\x3A-\x40\x5B-\x60\x7B-\x7E]) 
    > (?!^\s+) (?!.*\s+$)(?!.*\s{2,})^[\x20-\x7e]{16,128}$"
    >    S:          level="error">
    >    S:          New password does not meet complexity requirements
    >    S:        </loginSec:event>
    > Page 10:
    > 
    >    S:    <result code="2200">
    >    S:      <msg>Authentication error</msg>

    It may be nice to try giving back all the requirements... except that you can
    not always express all of them with a regular expression for once, and because
    there are different flavors of regular expressions for another reason,
    two points I already raised on the "policy" extension.

    Some registries may have requirements like: at least one letter and at least one
    digit and at least one "special" character.
    While this may still be done by a regex, it will not be nice (as you need to consider at the same time the range of characters allowed and the constraints on length), and yet there may
    be even harder cases, like "no sequence of repeating characters" 
    or like "at least 2 "special" character, but not twice the same one".

    Aside, there is RFC 7613 "Preparation, Enforcement, and Comparison of Internationalized Strings
                      Representing Usernames and Passwords" and it may be a good idea to reference it or derive from it. Note specifically sections 3.5 and 4.2.2 (that touches the other point raised about handling spaces, etc.)

    And I do not even touch things like:
    - checking if the password does not contain a known word for some definition of word in some dictionaries
    - checking if the password does not match any given leaked passwords (why not? some websites are already adding in their signup/login process a check if the password is among the list of leaked ones)
    - not reusing one of the X previously used password, or one of the previous passwords slightly changed like reversed or appended with 1, etc.

    Also, related, I would be interested into works that goes into the direction of not having to exchange the password in the clear at all (even if we are inside TLS), because the server does not need to have the client to send it, just to make sure it can prove it has it, and there are various mechanims existing for that (but they may be complicated to port to EPP as they may need further exchanges besides our current greeting/login).
    Like SRP and the example of RFC5054 "Using the Secure Remote Password (SRP) Protocol for TLS Authentication".

    Or at least, like I suggested on the policy extension, but that was not meant with a lot of enthusiasm, to implement SASL instead of the current purely login+password, so that at least other methods of authentication could be plugged in.

    -- 
      Patrick Mevzek
      pm@dotandco.com

    _______________________________________________
    regext mailing list
    regext@ietf.org
    https://www.ietf.org/mailman/listinfo/regext