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

Patrick,

I did the exercise of defining the PCRE the matches your password format policy, which can be verified using https://regex101.com.  The PCRE is defined below:

(?=.*[A-Z])(?=.*[a-z])(?=.*\d)(?=.*[.,:;!?-])(?!.*(.{2,}).*\1)(?!.*(.)\2)^[\x00-\x7F]{17,33}$

I breakdown the PCRE to meet each of your password format policy requirements below:

- any character from the Unicode Latin script

^[\x00-\x7F]{17,33}

- at least one uppercase, one lowercase, one digit, and one punctuation character (in no specific order)

(?=.*[A-Z])(?=.*[a-z])(?=.*\d)(?=.*[.,:;!?-])

- no repeated sequence of two or more characters

(?!.*(.{2,}).*\1)

- no given character repeated in sequence

(?!.*(.)\2)

- between 17 and 33 characters long in total

^[\x00-\x7F]{17,33}

Do you have any thoughts related to what additional password policies should be captured in draft-gould-regext-login-security-policy?

My thoughts include optionally defining the number of past passwords that cannot be used and defining a flag of whether the use of insecure words will be checked.

Should the <loginSecPolicy:pw><loginSecPolicy:expression> element be made optional to address a password format policy that a PCRE cannot be created for?

If a server cannot define their password format policy using a PCRE, I believe the policy may be too complex and should be re-evaluated.  My recommendation is to leave the <loginSecPolicy:pw><loginSecPolicy:expression> element as required.

Should the <loginSecPolicy:pw> element support a method to reference an external resource (e.g., url) that defines the password policy information?

An external resource would require manual intervention by the client, so I don’t recommend supporting an external resource.

Thanks,

—

JG

James Gould

Distinguished Engineer

jgould@Verisign.com

703-948-3271

12061 Bluemont Way

Reston, VA 20190

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

On 4/10/19, 10:18 AM, "regext on behalf of Patrick Mevzek" <regext-bounces@ietf.org on behalf of pm@dotandco.com> wrote:

    On Wed, Apr 10, 2019, at 08:26, Gould, James wrote:

    > I believe that a PCRE can effectively express the password format policy for EPP; although there may be exceptions to the rule.

    [..]

    > I believe your password format policy can be expressed via a PCRE, but

    > I’ll leave that exercise to you.

    Ok, so there is no proof, just beliefs.

    Hence, I will still object to having PCRE used in that way, because they are just not fit for the job.

    > The question is whether there are existing or planned EPP

    > password format policies that cannot be expressed via a PCRE.

    I gave one example I think.

    Of course you are free to dismiss it and say "but the model works for 90% of cases", and then have an extension that works for 90% of cases which means on the field that multiple registries will instead just write their own (or not implement that one because they can not use it in their case). This is exactly why the world of EPP extensions is so fragmented. But I will rest my case here.

    --

      Patrick Mevzek

      pm@dotandco.com

    _______________________________________________

    regext mailing list

    regext@ietf.org

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