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

From: "Gould, James" <[email-masked]>
Date: Wed, 3 Apr 2019 22:20:01 +0000

Martin,

Thank you for doing a detailed review of draft-ietf-regext-login-security.  I provide my responses to your feedback embedded below.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

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

From: regext <[email-masked]> on behalf of Martin Casanova <[email-masked]>
Date: Tuesday, March 26, 2019 at 1:56 PM
To: "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] [regext] review of draft-ietf-regext-login-security-03

Jim

Since we support that draft I started implementing and read it again more carefully. I have the following comments / feedback

1. (comment) Event type "cipher" or "tlsProtocol" :

In case the client uses deprecated protocol or cipher we currently hang up the TLS connection immediately so there is no possibility to send a type "error" security event.
At chapter 3.1 near "exDate" is written that "At expiry there MAY be an error to connect or MAY be an error to login." So in case of an error to connect you run in the same situation and will not be able to send back a "error" level event but thats OK. However it is useful to warn the client during a transition period when we know that we are going to disable a certain cipher or TLS protocol on a specific day in the future.
JG – Yes, connectivity events like “cipher”, “tlsProtocol”, and “certificate” are really only useful when they are provided as a warning with an optional exDate to indicate when the event will result in a connection error.  The policies for the possible set of events can be defined using the Login Security Policy Extension (https://tools.ietf.org/html/draft-gould-regext-login-security-policy), which is an extension of the Registry Mapping (https://tools.ietf.org/html/draft-gould-carney-regext-registry).  The clients need to look for the security events in the login response to act on them.

2 . (comment) Event type “newPw”:
Here we currently use  2306 “Parameter value policy error” and write in the <reason> of <extValue> element that the new password was too weak.
I guess we would use the loginSec Event in the future in case the extension was specified at login whether the pw was changed via login-security extension or not.

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>

   S:    <result code=”2200”>

   S:      <msg>Authentication error</msg>

Are you sure you want to return a 2200 and not a 2306 Parameter value policy error in this case (page 10). I don’t see a reason why this should be another return code with or without extension.

JG – On the first part of your feedback, I’m not sure that we want to inject policy elements into the error response.  Of course the policy information could be embedded within the human readable message, such as below.  I don’t recommend the client parsing the human readable message for policy information, but this would be useful for logging and troubleshooting on the client-side.  One issue is that the client can only receive the password complexity expression upon an error.  It’s best to handle the password complexity expression out-of-band or via the Login Security Policy Extension (draft-gould-regext-login-security-policy) to enable the client to know about the policy prior to an error.

   S:        <loginSec:event

   S:          type=”newPW”

   S:          level=”error”>

   S:          New password does not meet complexity requirement: (?=.*\d)(?=.*[a-zA-Z])(?=.*[\x21-\x2F\x3A-\x40\x5B-\x60\x7B-\x7E]) (?!^\s+) (?!.*\s+$)(?!.*\s{2,})^[\x20-\x7e]{16,128}$

   S:        </loginSec:event>

JG – On the second part of your feedback, I believe that the login should fail if an invalid new password is passed with a 2200 “Authentication error”.  The use of 2200 is not normative, so the server could choose a different result code, such as 2306.  The Login Security Extension will provide more specific information associated with the error.  Are there thoughts from others related to which error result code (2200, 2306, or other) should be used for an invalid new password and whether it should be normative?

3. (question) Event type "stat" :

How often would you send back this event

   <loginSec:event

     type="stat"

     name="failedLogins"

     level="warning"

     value="100"

     duration="P1D">

     Excessive invalid daily logins

   </loginSec:event>

Only once with first successful login after the series of failed ones or for a whole day ? I suggest one time with first successful login.

JG – My thought is that returning the statistical information should not be stateful, so that means that the interval would be up to the server (e.g., for a one day duration start calculating the statistic based on a start / end of midnight UTC), but all applicable events would be returned in all login responses.  I do not recommend the server keeping track of which events have been returned and which have not been returned.  What are your thoughts on this?

4. (question) In chapter 4.1 EPP <login> Command is written

..

internal contiguous

       whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage

       return), and #x20 (space) is replaced with a single #x20 (space).

...

Since this is "normal" XML parsing behavior should there not be reference to where this is described for general XML processing. (I don't know where that would be though)

JG – The choice was to directly include the definition within the draft in place of referencing out.  I’m not aware of an RFC that can be referenced for the XML processing of an XML schema “token” type.  My recommendation is to leave the definition directly in the draft without an external reference.

5.  (suggestion) The element  <loginSec:userAgent> could be more structured to make it easier for the registry to parse the different fields and to give a hint to the registrar what information should be provided.

Therefore I suggest  child elements for example

<os>           Operating System
<client>      Client technology (eg. java)
<version> Client software version (eg. 1.8.0) etc.

JG – If we were going to make the <loginSec:userAgent> structured, my recommendation is to handle it with the following definition:

   <complexType name="userAgentType">

    <sequence>

      <element name="client" type="token"

       minOccurs="0"/>

      <element name="lang" type="token"

       minOccurs="0"/>

      <element name="os" type="token"

       minOccurs="0"/>

    </sequence>

   </complexType>

JG – Below would be an example structured <loginSec:userAgent> element:

   <loginSec:userAgent>

     <loginSec:client>EPP SDK 1.0.0</loginSec:client>

     <loginSec:lang>Java 11.0.2</loginSec:lang>

     <loginSec:os>x86_64 Mac OS X 10.21</loginSec:os>

   </loginSec:userAgent>

JG – What are your thoughts on the structured version of the <loginSec:userAgent> element.  If this works, I will revise the draft to support it.

Thanks

Martin Casanova

--

---

SWITCH

Martin Casanova, Domain Applications

Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland

phone +41 44 268 15 55, direct +41 44 268 16 25

[email-masked]<mailto:[email-masked]>, www.switch.ch<http://www.switch.ch>

Working for a better digital world

---

From: Martin Casanova <[email-masked]>
Date: Mon, 8 Apr 2019 12:27:36 +0200

Jim

Below my comments. Thanks.

MC

On 04.04.19 00:20, Gould, James wrote:
>
> Martin,
>
>  
>
> Thank you for doing a detailed review of
> draft-ietf-regext-login-security.  I provide my responses to your
> feedback embedded below.
>
>   
>
> —
>
>  
>
> JG
>
>
>
> *James Gould
> *Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>  
>
> *From: *regext <[email-masked]> on behalf of Martin Casanova
> <[email-masked]>
> *Date: *Tuesday, March 26, 2019 at 1:56 PM
> *To: *"[email-masked]" <[email-masked]>
> *Subject: *[EXTERNAL] [regext] review of
> draft-ietf-regext-login-security-03
>
>  
>
> Jim
>
> Since we support that draft I started implementing and read it again
> more carefully. I have the following comments / feedback
>
> In case the client uses deprecated protocol or cipher we currently
> hang up the TLS connection immediately so there is no possibility to
> send a type "error" security event.
> At chapter 3.1 near "exDate" is written that "At expiry there MAY be
> an error to connect or MAY be an error to login." So in case of an
> error to connect you run in the same situation and will not be able to
> send back a "error" level event but thats OK. However it is useful to
> warn the client during a transition period when we know that we are
> going to disable a certain cipher or TLS protocol on a specific day in
> the future.
>
> JG – Yes, connectivity events like “cipher”, “tlsProtocol”, and
> “certificate” are really only useful when they are provided as a
> warning with an optional exDate to indicate when the event will result
> in a connection error.  The policies for the possible set of events
> can be defined using the Login Security Policy Extension
> (https://tools.ietf.org/html/draft-gould-regext-login-security-policy),
> which is an extension of the Registry Mapping
> (https://tools.ietf.org/html/draft-gould-carney-regext-registry).  The
> clients need to look for the security events in the login response to
> act on them.       
>
MC -Agreed.

> Here we currently use  2306 “Parameter value policy error” and write
> in the <reason> of <extValue> element that the new password was too
> weak. 
> I guess we would use the loginSec Event in the future in case the
> extension was specified at login whether the pw was changed via
> login-security extension or not.
>
> 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”
> Are you sure you want to return a 2200 and not a 2306 Parameter value
> policy error in this case (page 10). I don’t see a reason why this
> should be another return code with or without extension.
>
> JG – On the first part of your feedback, I’m not sure that we want to
> inject policy elements into the error response.  Of course the policy
> information could be embedded within the human readable message, such
> as below.  I don’t recommend the client parsing the human readable
> message for policy information, but this would be useful for logging
> and troubleshooting on the client-side.  One issue is that the client
> can only receive the password complexity expression upon an error. 
> It’s best to handle the password complexity expression out-of-band or
> via the Login Security Policy Extension
> (draft-gould-regext-login-security-policy) to enable the client to
> know about the policy prior to an error.      
>
>    S:        <loginSec:event
>    S:          type=”newPW”
>    S:          level=”error”>

MC - agreed:  - useful for logging and troubleshooting on the
client-side, shouldn't be parsed.. Generally I think error feedback
should be as indicative of the problem as possible so the registrar
would not open a ticket at the registry to ask why the error occurred or
how it could be prevented. The out of band documentation is a must
anyway so these tickets will be answered by RTFM! as in many cases :)
I guess this is a "nice to have" but I also don't see a problem with
including this piece of policy information. It's not a policy
information that is enforced by XML Schema or so..

> JG – On the second part of your feedback, I believe that the login
> should fail if an invalid new password is passed with a 2200
> “Authentication error”.  The use of 2200 is not normative, so the
> server could choose a different result code, such as 2306.  The Login
> Security Extension will provide more specific information associated
> with the error.  Are there thoughts from others related to which error
> result code (2200, 2306, or other) should be used for an invalid new
> password and whether it should be normative?       
>
MC - RFC 5730

      2200    "Authentication error"

              This response code MUST be returned when a server notes an
              error when validating client credentials.

So I think 2200 is OK if you see <newpw> already as client credentials.
However a client could get confused with 2200 thinking the error code
relates to the <pw> filed which is correct. (if it wasn't for the
<loginSec:event>) What is your current return code when pw complexity is
not OK without using loginSec extension ? Ours is 2306..

> Only once with first successful login after the series of failed ones
> or for a whole day ? I suggest one time with first successful login.
>
> JG – My thought is that returning the statistical information should
> not be stateful, so that means that the interval would be up to the
> server (e.g., for a one day duration start calculating the statistic
> based on a start / end of midnight UTC), but all applicable events
> would be returned in all login responses.  I do not recommend the
> server keeping track of which events have been returned and which have
> not been returned.  What are your thoughts on this? 
>
MC -  Agreed that this should not be stateful and I wouldn't want to
persist anything for this. Currently we have a mechanism in place that
hangs up the existing session and blocks new TLS sessions for x seconds
when there were too many failed request in the past y seconds. We do
have a "sliding window" algorithm in place to determine whether a client
is currently blocked or nor not. We could use the same to inform at
every successful  login that a blocking event occurred in the last 24
hours (since now)

> Since this is "normal" XML parsing behavior should there not be
> reference to where this is described for general XML processing. (I
> don't know where that would be though)
>
> JG – The choice was to directly include the definition within the
> draft in place of referencing out.  I’m not aware of an RFC that can
> be referenced for the XML processing of an XML schema “token” type. 
> My recommendation is to leave the definition directly in the draft
> without an external reference.
>
MC - OK
>
> 5.  (suggestion) The element  <loginSec:userAgent> could be more
> structured to make it easier for the registry to parse the different
> fields and to give a hint to the registrar what information should be
> provided.
>
> JG – If we were going to make the <loginSec:userAgent> structured, my
> recommendation is to handle it with the following definition:
>
> JG – What are your thoughts on the structured version of the
> <loginSec:userAgent> element.  If this works, I will revise the draft
> to support it. 
>
MC -  Maybe the "lang" field is a bit misleading since "lang" also
exists in RFC 5730 where it has another meaning.

<element name="lang" type="language"
          maxOccurs="unbounded"/>

Hopefully nobody would fill it out with "EN".. So maybe we could find
another terminology. How about "tec" for technology ?

The information  that would be interesting to us is

- Client application and version (eg. EPP SDK 1.0.0)
- Client technology  and version (eg. openjdk version "1.8.0_191" or
Perl or ?)
- Client OS and version (eg.|Distributor ID:    Ubuntu  Description:  
 Ubuntu 16.04.5 LTS)|)

So the version is important too to decide if a client is affected by
some security issues but maybe this would be an overkill to enforce /
"ask for" or not ?

Other than that I have currently no feedback - so looking forward to the
next next revision..

> [email-masked] <mailto:[email-masked]>, www.switch.ch <http://www.switch.ch> 
>  

-- 
--- 
SWITCH 
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland 
phone +41 44 268 15 55, direct +41 44 268 16 25
[email-masked], www.switch.ch

---

From: "Gould, James" <[email-masked]>
Date: Mon, 8 Apr 2019 13:23:08 +0000

Martin,

I include my comments embedded below.

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

From: Martin Casanova <[email-masked]>
Date: Monday, April 8, 2019 at 6:28 AM
To: James Gould <[email-masked]>, "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] review of draft-ietf-regext-login-security-03

Jim

MC

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

From: regext <[email-masked]><mailto:[email-masked]> on behalf of Martin Casanova <[email-masked]><mailto:[email-masked]>
Date: Tuesday, March 26, 2019 at 1:56 PM
To: "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [EXTERNAL] [regext] review of draft-ietf-regext-login-security-03

Jim

MC -Agreed.

Maybe like that

   S:        <loginSec:event

   S:          type=”newPW”

   S:          level=”error”>

   S:        </loginSec:event>

   S:    <result code=”2200”>

   S:        <loginSec:event

   S:          type=”newPW”

   S:          level=”error”>

   S:        </loginSec:event>

MC - agreed:  - useful for logging and troubleshooting on the client-side, shouldn't be parsed.. Generally I think error feedback should be as indicative of the problem as possible so the registrar would not open a ticket at the registry to ask why the error occurred or how it could be prevented. The out of band documentation is a must anyway so these tickets will be answered by RTFM! as in many cases :)
I guess this is a "nice to have" but I also don't see a problem with including this piece of policy information. It's not a policy information that is enforced by XML Schema or so..

JG – Inclusion of the password complexity policy can be included in the event message as a “nice to have”, but I recommend that we leave this out of the draft.

MC - RFC 5730

So I think 2200 is OK if you see <newpw> already as client credentials. However a client could get confused with 2200 thinking the error code relates to the <pw> filed which is correct. (if it wasn't for the <loginSec:event>) What is your current return code when pw complexity is not OK without using loginSec extension ? Ours is 2306..

JG – If passing an invalid new password results in a failure of the login, then we would return a 2200.  Inclusion of the “newPw” Login Security Extension event in the error response should help to clarify the cause of the 2200.

   <loginSec:event

     type="stat"

     name="failedLogins"

     level="warning"

     value="100"

     duration="P1D">

   </loginSec:event>

MC -  Agreed that this should not be stateful and I wouldn't want to persist anything for this. Currently we have a mechanism in place that hangs up the existing session and blocks new TLS sessions for x seconds when there were too many failed request in the past y seconds. We do have a "sliding window" algorithm in place to determine whether a client is currently blocked or nor not. We could use the same to inform at every successful  login that a blocking event occurred in the last 24 hours (since now)

JG – Do you block the connection or new logins attempts?  If it’s the ladder, is there the need for a new Login Security event type to cover this use case?  Something like the following could be returned on a failed login response due to a blocked client.  I view the blocking as a separate security event from the “stat” event type, since the “stat” event type is meant to be informative.

   <loginSec:event

     type=”blocked”

     level=”error”

     duration=”PT5M”>

     Client login blocked for 5 more minutes

   </loginSec:event>

..

internal contiguous

...

Since this is “normal” XML parsing behavior should there not be reference to where this is described for general XML processing. (I don’t know where that would be though)

MC – OK

<os>           Operating System
<client>      Client technology (eg. Java)
<version> Client software version (eg. 1.8.0) etc.

   <complexType name=”userAgentType”>

    <sequence>

      <element name=”client” type=”token”

       minOccurs=”0”/>

      <element name=”lang” type=”token”

       minOccurs=”0”/>

      <element name=”os” type=”token”

       minOccurs=”0”/>

    </sequence>

   </complexType>

   <loginSec:userAgent>

   </loginSec:userAgent>

MC -  Maybe the “lang” field is a bit misleading since “lang” also exists in RFC 5730 where it has another meaning.

<element name=”lang” type=”language”

          maxOccurs=”unbounded”/>

Hopefully nobody would fill it out with “EN”.. So maybe we could find another terminology. How about “tec” for technology ?
The information  that would be interesting to us is

- Client application and version (eg. EPP SDK 1.0.0)
- Client technology  and version (eg. Openjdk version “1.8.0_191” or Perl or ?)
- Client OS and version (eg. Distributor ID:    Ubuntu  Description:    Ubuntu 16.04.5 LTS))

So the version is important too to decide if a client is affected by some security issues but maybe this would be an overkill to enforce / “ask for” or not ?

JG – The <loginSec:client> element can be changed to the <loginSec:app> element.  To remove confusion for “lang”, how about changing the <loginSec:lang> element to the <loginSec:tech> element.  The description of the app, tech, and os elements would encourage the inclusion of the version.  The following is the proposed description of the elements:

       <loginSec:app>:  OPTIONAL name of the client application software with version if available, such as the name of the client SDK "EPP SDK 1.0.0".

       <loginSec:tech>:  OPTIONAL technology used for the client software with version if available, such as "Java 11.0.2".

       <loginSec:os>:  OPTIONAL client operating system used with version if available, such as "x86_64 Mac OS X 10.11.6"

The resulting <loginSec:userAgent> would be:

   <loginSec:userAgent>

     <loginSec:app>EPP SDK 1.0.0</loginSec:app>

     <loginSec:tech>Java 11.0.2</loginSec:tech>

   </loginSec:userAgent>

  Does this work?

Other than that I have currently no feedback - so looking forward to the next next revision..

Thanks

Martin Casanova

--

---

SWITCH

--

---

SWITCH

---

From: Martin Casanova <[email-masked]>
Date: Tue, 9 Apr 2019 13:12:30 +0200

Jim

I am happy with the latest suggestions and the userAgent fields: app /
tech / os

JG – Do you block the connection or new logins attempts?  If it’s the
ladder, is there the need for a new Login Security event type to cover
this use case?  Something like the following could be returned on a
failed login response due to a blocked client.  I view the blocking as a
separate security event from the “stat” event type, since the “stat”
event type is meant to be informative. 

   <loginSec:event

     type=”blocked”

     level=”error”

     duration=”PT5M”>

   </loginSec:event>

MC - In fact we do disconnect the TLS connection immediately (without
even sending a greeting) if the client is in status BLOCKED.
But I was thinking it would maybe be interesting to the client that this
BLOCKED state occurred at the next successful login (which is only
possible after the BLOCKED period has expired).
Maybe there are similar mechanisms in place at other registries that
prevent brute force attacks on the credentials of registrars. I think
this could be handled with the existing stat event.

   <loginSec:event
     type="stat"
     name="failed blocked"
     level="warning"
     value="x failed commands / y min"
     duration="P1D">
     Client has been blocked because of too many failed requests
   </loginSec:event>

We also do have a rate limit in place that checks that clients only can
send x requests in y seconds... If the rate is exceeded for too long the
response of the current command is delayed x seconds (timeout)

and the new commands are not accepted anymore but answered right away with

  <response>
    <result code="2500">
      <msg lang="en">Command failed; server closing connection</msg>
      <extValue>
        <value>
          <epp />
        </value>
        <reason lang="en">Too many requests per second! Timeout ms.:
#####</reason>
      </extValue>
    </result>
    <trID>
     <dont_check>$dont_check$</dont_check>
    </trID>
  </response>

this could also result in a waring event at next login but the above
response gives already a hint:

   <loginSec:event
     type="stat"
     name="quota timeout"
     level="warning"
     value="x commands / y min"
     duration="P1D">
     Quota was exceeded
   </loginSec:event>

Do you have similar mechanisms in place ?
I think draft-gould-casanova-regext-unhandled-namespaces would allow to
put loginSec:event in the <extValue> element analogous to the RGP
example in chapter 4.0 so when we are implementing loginSec we would do
it in compliance to the unhandled-namespaces in case the 
urn:ietf:params:xml:ns:epp:loginSec-0.3 was not specified in 
<svcExtension>  <svcs>...

Martin

On 08.04.19 15:23, Gould, James wrote:
> *From: *Martin Casanova <[email-masked]>
> *Date: *Monday, April 8, 2019 at 6:28 AM
> *To: *James Gould <[email-masked]>, "[email-masked]"
> <[email-masked]>
> *Subject: *[EXTERNAL] Re: [regext] review of
>     *From: *regext <[email-masked]>
>     <mailto:[email-masked]> on behalf of Martin Casanova
>     <[email-masked]> <mailto:[email-masked]>
>     *To: *"[email-masked]" <mailto:[email-masked]> <[email-masked]>
>     <mailto:[email-masked]>
>     Since we support that draft I started implementing and read it
>     again more carefully. I have the following comments / feedback
>
>     hang up the TLS connection immediately so there is no possibility
>     to send a type "error" security event.
>     At chapter 3.1 near "exDate" is written that "At expiry there MAY
>     be an error to connect or MAY be an error to login." So in case of
>     an error to connect you run in the same situation and will not be
>     able to send back a "error" level event but thats OK. However it
>     is useful to warn the client during a transition period when we
>     know that we are going to disable a certain cipher or TLS protocol
>     on a specific day in the future.
>
>     warning with an optional exDate to indicate when the event will
>     result in a connection error.  The policies for the possible set
>     of events can be defined using the Login Security Policy Extension
>     (https://tools.ietf.org/html/draft-gould-carney-regext-registry). 
>     The clients need to look for the security events in the login
>     response to act on them.       
>
> MC -Agreed.
>
>  
>
>     Here we currently use  2306 “Parameter value policy error” and
>     write in the <reason> of <extValue> element that the new password
>     was too weak. 
>     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”
>
>     Are you sure you want to return a 2200 and not a 2306 Parameter
>     value policy error in this case (page 10). I don’t see a reason
>     why this should be another return code with or without extension.
>
>     JG – On the first part of your feedback, I’m not sure that we want
>     to inject policy elements into the error response.  Of course the
>     policy information could be embedded within the human readable
>     message, such as below.  I don’t recommend the client parsing the
>     human readable message for policy information, but this would be
>     useful for logging and troubleshooting on the client-side.  One
>     issue is that the client can only receive the password complexity
>     expression upon an error.  It’s best to handle the password
>     complexity expression out-of-band or via the Login Security Policy
>     Extension (draft-gould-regext-login-security-policy) to enable the
>     client to know about the policy prior to an error.      
>
>        S:        <loginSec:event
>
>        S:          type=”newPW”
>
>        S:          level=”error”>
>
> would not open a ticket at the registry to ask why the error occurred
> or how it could be prevented. The out of band documentation is a must
> JG – Inclusion of the password complexity policy can be included in
> the event message as a “nice to have”, but I recommend that we leave
> this out of the draft.     
>
>     server could choose a different result code, such as 2306.  The
>     Login Security Extension will provide more specific information
>     associated with the error.  Are there thoughts from others related
>     to which error result code (2200, 2306, or other) should be used
>     for an invalid new password and whether it should be normative? 
>          
>
> MC - RFC 5730
>
> So I think 2200 is OK if you see <newpw> already as client
> credentials. However a client could get confused with 2200 thinking
> the error code relates to the <pw> filed which is correct. (if it
> wasn't for the <loginSec:event>) What is your current return code when
> pw complexity is not OK without using loginSec extension ? Ours is 2306..
>
>      
>
>     JG – If passing an invalid new password results in a failure of
>     the login, then we would return a 2200.  Inclusion of the “newPw”
>     Login Security Extension event in the error response should help
>     to clarify the cause of the 2200. 
>
>
>
>     Only once with first successful login after the series of failed
>     ones or for a whole day ? I suggest one time with first successful
>     login.
>
>     JG – My thought is that returning the statistical information
>     should not be stateful, so that means that the interval would be
>     up to the server (e.g., for a one day duration start calculating
>     the statistic based on a start / end of midnight UTC), but all
>     applicable events would be returned in all login responses.  I do
>     not recommend the server keeping track of which events have been
>     returned and which have not been returned.  What are your thoughts
>     on this? 
>
> hangs up the existing session and blocks new TLS sessions for x
> seconds when there were too many failed request in the past y seconds.
> We do have a "sliding window" algorithm in place to determine whether
> a client is currently blocked or nor not. We could use the same to
> inform at every successful  login that a blocking event occurred in
> the last 24 hours (since now)
>
>  
>
> JG – Do you block the connection or new logins attempts?  If it’s the
> ladder, is there the need for a new Login Security event type to cover
> this use case?  Something like the following could be returned on a
> failed login response due to a blocked client.  I view the blocking as
> a separate security event from the “stat” event type, since the “stat”
> event type is meant to be informative. 
>
>    <loginSec:event
>      type=”blocked”
>      level=”error”
>      duration=”PT5M”>
>     Since this is “normal” XML parsing behavior should there not be
>     reference to where this is described for general XML processing.
>     (I don’t know where that would be though)
>
>     draft in place of referencing out.  I’m not aware of an RFC that
>     can be referenced for the XML processing of an XML schema “token”
>     type.  My recommendation is to leave the definition directly in
>     the draft without an external reference.
>
> MC – OK
>
>     structured to make it easier for the registry to parse the
>     different fields and to give a hint to the registrar what
>     information should be provided.
>
>     JG – If we were going to make the <loginSec:userAgent> structured,
>     my recommendation is to handle it with the following definition:
>
>     <loginSec:userAgent> element.  If this works, I will revise the
>     draft to support it. 
>
> MC -  Maybe the “lang” field is a bit misleading since “lang” also
> Hopefully nobody would fill it out with “EN”.. So maybe we could find
> another terminology. How about “tec” for technology ?
>
> - Client OS and version (eg.Distributor ID:    Ubuntu  Description:  
>  Ubuntu 16.04.5 LTS))
>
> “ask for” or not ?
> JG – The <loginSec:client> element can be changed to the
> <loginSec:app> element.  To remove confusion for “lang”, how about
> changing the <loginSec:lang> element to the <loginSec:tech> element. 
> The description of the app, tech, and os elements would encourage the
> inclusion of the version.  The following is the proposed description
> of the elements:
>
>        <loginSec:app>:  OPTIONAL name of the client application
> software with version if available, such as the name of the client SDK
> "EPP SDK 1.0.0".
>
>        <loginSec:tech>:  OPTIONAL technology used for the client
> software with version if available, such as "Java 11.0.2".
>
>        <loginSec:os>:  OPTIONAL client operating system used with
> version if available, such as "x86_64 Mac OS X 10.11.6"
>

---

From: "Gould, James" <[email-masked]>
Date: Tue, 9 Apr 2019 14:15:19 +0000

Martin,

I am happy with the latest suggestions and the userAgent fields: app / tech / os
JG - I will go ahead and post draft-ietf-regext-login-security-01 with this change.

JG – For the blocking and rate limiting, I believe that the existing “stat” event type will serve the purpose.

I think draft-gould-casanova-regext-unhandled-namespaces would allow to put loginSec:event in the <extValue> element analogous to the RGP example in chapter 4.0 so when we are implementing loginSec we would do it in compliance to the unhandled-namespaces in case the  urn:ietf:params:xml:ns:epp:loginSec-0.3 was not specified in  <svcExtension>  <svcs>...
JG – Yes, draft-gould-casanova-regext-unhandled-namespaces can be used to return the security event information to clients that don’t explicitly support the urn:ietf:params:xml:ns:epp:loginSec-0.3 and now the urn:ietf:params:xml:ns:epp:loginSec-0.4 namespaces.  Below is an example of returning the password expiry warning event using draft-gould-casanova-regext-unhandled-namespaces.

<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
  <response>
    <result code="1000">
      <msg>Command completed successfully</msg>
      <extValue>
        <value>
          <loginSec:loginSecData
            xmlns:loginSec=
              "urn:ietf:params:xml:ns:epp:loginSec-0.4">
            <loginSec:event
              type="password"
              level="warning"
              exDate="2018-04-01T22:00:00.0Z"
              lang="en">
              Password expiration soon
            </loginSec:event>
          </loginSec:loginSecData>
        </value>
        <reason>
          urn:ietf:params:xml:ns:epp:loginSec-0.4 not in login services
        </reason>
      </extValue>
    </result>
    <trID>
      <clTRID>ABC-12345</clTRID>
      <svTRID>54321-XYZ</svTRID>
    </trID>
  </response>
</epp>

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

From: regext <[email-masked]> on behalf of Martin Casanova <[email-masked]>
Date: Tuesday, April 9, 2019 at 7:14 AM
To: "[email-masked]" <[email-masked]>
Subject: [EXTERNAL] Re: [regext] review of draft-ietf-regext-login-security-03

Jim

I am happy with the latest suggestions and the userAgent fields: app / tech / os

   <loginSec:event

     type=”blocked”

     level=”error”

     duration=”PT5M”>

   </loginSec:event>

MC - In fact we do disconnect the TLS connection immediately (without even sending a greeting) if the client is in status BLOCKED.
But I was thinking it would maybe be interesting to the client that this BLOCKED state occurred at the next successful login (which is only possible after the BLOCKED period has expired).
Maybe there are similar mechanisms in place at other registries that prevent brute force attacks on the credentials of registrars. I think this could be handled with the existing stat event.

   <loginSec:event

     type="stat"

     name="failed blocked"

     level="warning"

     duration="P1D">

   </loginSec:event>

We also do have a rate limit in place that checks that clients only can send x requests in y seconds... If the rate is exceeded for too long the response of the current command is delayed x seconds (timeout)

  <response>
    <result code="2500">
      <msg lang="en">Command failed; server closing connection</msg>
      <extValue>
        <value>
          <epp />
        </value>
        <reason lang="en">Too many requests per second! Timeout ms.: #####</reason>
      </extValue>
    </result>
    <trID>
     <dont_check>$dont_check$</dont_check>
    </trID>
  </response>

this could also result in a waring event at next login but the above response gives already a hint:

   <loginSec:event

     type="stat"

     name="quota timeout"

     level="warning"

     duration="P1D">

     Quota was exceeded

   </loginSec:event>

Do you have similar mechanisms in place ?
I think draft-gould-casanova-regext-unhandled-namespaces would allow to put loginSec:event in the <extValue> element analogous to the RGP example in chapter 4.0 so when we are implementing loginSec we would do it in compliance to the unhandled-namespaces in case the  urn:ietf:params:xml:ns:epp:loginSec-0.3 was not specified in  <svcExtension>  <svcs>...

Martin

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

From: Martin Casanova <[email-masked]><mailto:[email-masked]>
Date: Monday, April 8, 2019 at 6:28 AM
To: James Gould <[email-masked]><mailto:[email-masked]>, "[email-masked]"<mailto:[email-masked]> <[email-masked]><mailto:[email-masked]>
Subject: [EXTERNAL] Re: [regext] review of draft-ietf-regext-login-security-03

Jim

MC

—

JG

James Gould
Distinguished Engineer
[email-masked]

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

Jim

MC -Agreed.

Maybe like that

   S:        <loginSec:event

   S:          type=”newPW”

   S:          level=”error”>

   S:        </loginSec:event>

   S:    <result code=”2200”>

   S:        <loginSec:event

   S:          type=”newPW”

   S:          level=”error”>

   S:        </loginSec:event>

MC - RFC 5730

   <loginSec:event

     type="stat"

     name="failedLogins"

     level="warning"

     value="100"

     duration="P1D">

   </loginSec:event>

   <loginSec:event

     type=”blocked”

     level=”error”

     duration=”PT5M”>

   </loginSec:event>

..

internal contiguous

...

<os>           Operating System

    <sequence>

       minOccurs=”0”/>

       minOccurs=”0”/>

       minOccurs=”0”/>

    </sequence>

   </complexType>

   <loginSec:userAgent>

   </loginSec:userAgent>

          maxOccurs=”unbounded”/>

   <loginSec:userAgent>

   </loginSec:userAgent>

  Does this work?

Thanks

Martin Casanova

--

---

SWITCH

--

---

SWITCH

--

---

SWITCH

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 09 Apr 2019 13:26:37 -0400

On Mon, Apr 8, 2019, at 08:23, Gould, James wrote:
> JG – The <loginSec:client> element can be changed to the <loginSec:app> 
> element. To remove confusion for “lang”, how about changing the 
> <loginSec:lang> element to the <loginSec:tech> element. The description 
> of the app, tech, and os elements would encourage the inclusion of the 
> version. The following is the proposed description of the elements:
> 
>  <loginSec:app>: OPTIONAL name of the client application software with 
> version if available, such as the name of the client SDK "EPP SDK 
> 1.0.0".
> 
>  <loginSec:tech>: OPTIONAL technology used for the client software with 
> version if available, such as "Java 11.0.2".

Please do not use "tech". Some EPP extensions already uses tech, albeit
in a "contact" related namespace, that is they have
<contact:tech>FOOBAR</contact:tech>
instead of this other form that some may prefer:
<domain:contact type="tech">FOOBAR</domain:contact>

So this falls in the kind of same problem of (non technical but possible confusing) collision.

And more generally, "tech" is too short to convey enough meaning just by itself.

In general I also fail to see what we gain by using short names.
Why not application, technology and operationSystem if you want all those details?

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 09 Apr 2019 13:49:44 -0400

On Tue, Mar 26, 2019, at 12:56, Martin Casanova wrote:
> 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">
> Page 10:
>    S:    <result code="2200">

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
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Tue, 9 Apr 2019 21:01:01 +0000

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
[email-masked]

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

On 4/9/19, 1:50 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

    

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

---

From: "Gould, James" <[email-masked]>
Date: Tue, 9 Apr 2019 21:19:15 +0000

Patrick,

I believe the most important aspect is that there are three separate sub-elements to make the <loginSec:userAgent> element structured.  There will not be any confusion with "tech" contact attribute value and the draft describes the meaning of each of the sub-elements.  My preference is to leave the sub-elements as defined in draft-ietf-regext-login-security-04.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 4/9/19, 1:26 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

    
    -- 
      Patrick Mevzek
      [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 09 Apr 2019 17:18:50 -0400

On Tue, Apr 9, 2019, at 16:01, Gould, James wrote:
> 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.        

That was exactly Martin's point on which I was replying:
<quote>
</quote>

And the example given clearly used an attribute to store the regex, which is clearly not 
human redable.

And again there is no "password expression" since like I tried to show but failed apparently, not all password policies can be compressed into one regular expression.

And also putting such kind of things (regex) into a "human" readable message makes no sense.
(it is neither human nor readable)

It would be far more logical to have a human readable message saying:
"Password not in compliance with rule A.III.b.3.i of regulations at https://www.registry.example/a_super_nice_documentation.pdf"

So my point was:
- don't think password policies can be condensed into a regular expression (that may be the case for one registry, but certainly not for all, so I see no need to try enforcing that)
- don't put things like that in "human" readable parts

Finally, like I said, piggybacking everything on another EPP extension risks for now the fact that not a lot of registries will implement it.
Each extension should try to stand-alone as much as possible...
Otherwise in your current setup a registry needs to implement this extension, the core policy one, and then the extension on the policy one. I have low hope this will happen... And the amount of discussions around this 

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 09 Apr 2019 17:26:50 -0400

On Tue, Apr 9, 2019, at 16:19, Gould, James wrote:
> I believe the most important aspect is that there are three separate 
> sub-elements to make the <loginSec:userAgent> element structured.

If you just want to record a structure with 3 elements, a sequence is enough,
you do not need explicit naming of each item.

> There will not be any confusion with "tech" contact attribute value and 
> the draft describes the meaning of each of the sub-elements.

You could have then arrived to the exact same conclusion with this reasoning for the "lang" attribute, yet you changed it. So we could as well go back to "lang" now.

For the record, I am against both "lang" and "tech", but those are minor points, like expressed previously I think there are other problems more important but I won't reiterate and I would be happy to see other registries implementing it, simply as there is no other option on the table anyway.
But again if we go the whole standardization process for an extension used only by a few players, I am not sure how much of the "E" in "EPP" we do leverage. Or if we leverage it too much in fact.

As in other cases, it would be good to see other registries/registrars voice their opinion, or even better implement it or something else or explicitely not for some reasons, etc.

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Tue, 9 Apr 2019 21:37:34 +0000

Patrick,

So my point was:

I’m not claiming that all password policies can be condensed into a regular expression, but at a minimum the syntactical policy can.  Other factors associated with the password policy can be handled in discussions around draft-gould-regext-login-security-policy.

I’m not proposing that password expression should be placed in the human readable message, but I’m pointing out that it can if a server desires to do so.  The server can also place the example message that you provided.  The draft does not need to define what is provided in the human readable message.

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 4/9/19, 5:21 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    <quote>

    </quote>

    human redable.

    So my point was:

    --

      Patrick Mevzek

      [email-masked]

    regext mailing list

    [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 09 Apr 2019 18:05:34 -0400

On Tue, Apr 9, 2019, at 16:37, Gould, James wrote:
> I’m not claiming that all password policies can be condensed into a 
> regular expression, but at a minimum the syntactical policy can.

Ok.
I am still curious to know the valid regex encoding this policy for example:

- any character from the Unicode Latin script
- at least one uppercase, one lowercase, one digit, and one punctuation character (in no specific order)
- no repeated sequence of two or more characters
- no given character repeated in sequence
- between 17 and 33 characters long in total

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Wed, 10 Apr 2019 13:26:07 +0000

Patrick,

We are discussing how to express the password format policy in draft-gould-regext-login-security-policy, which uses a Perl-compatible Regular Expression (PCRE).  The use of a PCRE was discussed at the REGEXT Interim Meeting 2018OCT16  (https://mailarchive.ietf.org/arch/msg/regext/3VWY7MlELXmEu5GdQbGnm70Im30).  I believe that a PCRE can effectively express the password format policy for EPP; although there may be exceptions to the rule.  Below I include an example EPP password format policy from draft-gould-regext-login-security-policy that uses a PCRE with a matching description.  A client can generate and pre-verify a new EPP password by leveraging the PCRE.

     <loginSecPolicy:pw>

       <loginSecPolicy:expression>

         (?=.*\d)

         (?=.*[a-zA-Z])

         (?=.*[\x21-\x2F\x3A-\x40\x5B-\x60\x7B-\x7E])

         (?!^\s+)

         (?!.*\s+$)

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

         ^[\x20-\x7e]{16,128}$

       </loginSecPolicy:expression>

       <loginSecPolicy:description>

         16 to 128 printable characters (alphanumeric, space, and

         special characters) with at least one number, letter, and

         special character, with no leading or trailing whitespace,

         and with no consecutive spaces.

       </loginSecPolicy:description>

     </loginSecPolicy:pw>

I believe your password format policy can be expressed via a PCRE, but I’ll leave that exercise to you.

Currently draft-gould-regext-login-security-policy has the <loginSecPolicy:pw><loginSecPolicy:expression> element defined as required.  The question is whether there are existing or planned EPP password format policies that cannot be expressed via a PCRE.  If so, we can adjust draft-gould-regext-login-security-policy to support providing an external URL reference or make the <loginSecPolicy:pw><loginSecPolicy:expression> element optional, so that the server only provides the description.  Other possible password policy elements are not defined in draft-gould-regext-login-security-policy, like use of prior passwords or use of insecure words.  Should such non-format policies be defined in draft-gould-regext-login-security-policy and if so what policies should be defined?

Thanks,

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 4/9/19, 6:06 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    Ok.

    --

      Patrick Mevzek

      [email-masked]

    regext mailing list

    [email-masked]

---

From: "Patrick Mevzek" <[email-masked]>
Date: Wed, 10 Apr 2019 10:18:29 -0400

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’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
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Wed, 10 Apr 2019 17:54:09 +0000

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:

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

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

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

(?!.*(.)\2)

^[\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

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 4/10/19, 10:18 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    [..]

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

    > I’ll leave that exercise to you.

    --

      Patrick Mevzek

      [email-masked]

    regext mailing list

    [email-masked]