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

From: "Patrick Mevzek" <[email-masked]>
Date: Mon, 01 Jul 2019 23:40:11 -0500

Hi James,

On Wed, Apr 10, 2019, at 12:54, Gould, James wrote:
>  
> 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}$*

Thanks to have taken the time to prove me wrong, I bow in front of that,
but maybe you could agree that it is neither easy to write, nor to read,
and that as beautiful as it may be in general, it still can not cover 100% of
cases, because the world is like it is and regular expressions solve many problems
but not all.
So I would still claim that a regex will not be able in all cases to encode
the registry policy on passwords but you can say that it will code for the most
frequent cases/the more important subcases, and additions can be expressed in human
documents, such as it is today, so regex already go a little further than current situation.

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

I do not think anyone follows me there, so you can probably keep it mandatory...
and a registry can publish its regex to be ^.*$ which will accomodate all cases.
 
> 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. 

Maybe, but that is a business/policy problem not a protocol problem. I would disapprove
any IETF document stating which passwords policies are too complex or not and
need to be re-evaluated. Besides generic discussion on strength based on the
count of possible different values.

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

That would then be only for human consumption, an EPP client won't be doing
anything  with it, so providing that URL through EPP does not provide any gain
I believe.
 
-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Mon, 8 Jul 2019 18:57:16 +0000

Patrick,

Use of the PCRE to define the password format policy is meant for machine consumption, so "easy to read" is not a factor.  The description is meant to be human readable and "easy to read".  

Do you have a specific example of an EPP password format that cannot be defined using a PCRE?  
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

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

On 7/2/19, 12:40 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    Hi James,

    

    

     
    -- 
      Patrick Mevzek
      [email-masked]
    
    _______________________________________________
    regext mailing list
    [email-masked]
    https://www.ietf.org/mailman/listinfo/regext

---

From: "Patrick Mevzek" <[email-masked]>
Date: Wed, 24 Jul 2019 23:57:22 -0500

On Mon, Jul 8, 2019, at 13:57, Gould, James wrote:
> Use of the PCRE to define the password format policy is meant for 
> machine consumption, so "easy to read" is not a factor.  The 
> description is meant to be human readable and "easy to read".  
> 

I think you are switching between format and policy while I am clearly stating
that even if a regex could encode (most, but I would not guarantee all) formats,
it certainly can not deal with policy in all generic cases.

Here is an example of a policy from a registry I am sure you know very well:
"Passwords should be changed every 12 months and should be different than the previous 6 passwords."

This can not be reflected in a regular expression.
You can put that as free text anywhere: then you do not achieve more than current documentation for human consumption
Or you decide to try to model things like that with a specific XML schema,
and while you technically could, I highly doubt you can make that flexible enough to handle
all registries different policies.

So in the end, the goal to define the policy around passwords is not met for me
(just because it can't be met, so it is maybe just a matter of aligning the goal),
, while the goal to define the syntax of passwords can be met.

I think we just disagree on the question if that second goal is good enough
or not.
But I would at least suggest that the draft is clearer on what it defines,
policy or format.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Thu, 25 Jul 2019 11:41:50 +0000

Patrick,

The use of the PCRE in draft-gould-regext-login-security-policy  was solely meant to define the format policy.  The other password policies can be able to be defined in a consumable manner.  For "Passwords should be changed every 12 months and should be different than the previous 6 passwords.", the changing of the password every 12 months would be covered with the policy definition of the "password" security event, as in:

     <loginSecPolicy:event type="password">
       <loginSecPolicy:level>warning</loginSecPolicy:level>
       <loginSecPolicy:level>error</loginSecPolicy:level>
       <loginSecPolicy:exDate>true</loginSecPolicy:exDate>
       <loginSecPolicy:exPeriod>P1Y</loginSecPolicy:exPeriod>
       <loginSecPolicy:warningPeriod>P15D</loginSecPolicy:warningPeriod>
       <loginSecPolicy:errorAction>login</loginSecPolicy:errorAction>
     </loginSecPolicy:event>

Covering the policy associated with the use of the previous 6 passwords is currently not covered by draft-gould-regext-login-security-policy, but I can add support for it.  

Thanks,

-- 
 
JG

James Gould
Distinguished Engineer
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

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

On 7/25/19, 12:58 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

    

    -- 
      Patrick Mevzek
      [email-masked]