Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Patrick Mevzek]

On Thu, Jun 14, 2018, at 15:12, Gould, James wrote:
> We can consider alternative authentication options if there is a 
> concrete proposal and the proposal does provide a security enhancement. 

It has alreay been proposed to be able to use non-plain passwords 
authentication

> I 
> reviewed the RFCs that you referenced (SASL and PRECIS) and I don’t see 
> anything in them that defines an alternative authentication mechanism 
> for EPP. 

SASL define a framework to be able to easily handle various authentication 
meachinism, like plain and hashed password at the same time.
This allows for more extensibility.

PRECIS define a framework to deal with "internationalized" strings in 
application, and this covers both usernames and passwords. It gives idea on how 
to define a profile (and I still remain unconvinced of the need to remove space 
from the passwords accepted for EPP, again because it is not a password that a 
human will use).

I believe they both could be useful starting block  (as they exist and are IETF 
standards) if these parts needs to be changed/enhanced in EPP.

Incidently, when they are more and more discussions around the subject of "how 
could a third party, like a DNS provider, mandated in some way by the 
registrant be able to do changes on the domain on its behalf without having to 
rely on the registrar", that SASL also handle OAUTH-types of authentication...

> Creating additional authentication options in EPP may result 
> in less security, so it would be good to understand what security aspect 
> needs to be fixed prior to creating additional options.

You never replied on the case of non-plain password authentication.
Can you share how it results on less security, and why the *possibility* (then 
it is up to the registry to use it or not) of providing it is not useful to 
consider?

Case in point for example: having it makes handling logging in a simpler way as 
password does not need to be specifically searched and obfuscated then for 
security reasons. People looking at logs in both sides would not be able to 
gain any knowledge of the password used.

-- 
  Patrick Mevzek
  p...@dotandco.com

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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Gould, James]

> JG - I don’t believe there is any desire to switch from using the

> variant of the PLAIN SASL mechanism [RFC4616] defined in the existing

> EPP RFC [RFC5730].



I do not know. My main point was more around: if we decide to put more energy 
into "securing" EPP better, providing more options than just plain text 
passwords (as asked by Pieter also I think) would be now a good time to think 
about, and if we go towards some "extensibility"  in authentication frameworks, 
why not just build on existing RFCs?



We can consider alternative authentication options if there is a concrete 
proposal and the proposal does provide a security enhancement.  Currently, most 
EPP registries support multi-factor authentication with the combination of user 
name / password and client certificate / client IP address.  The RFC 5730 16 
character maximum password is a undesirable constraint that is addressed via 
draft-gould-regext-login-security.  I reviewed the RFCs that you referenced 
(SASL and PRECIS) and I don’t see anything in them that defines an alternative 
authentication mechanism for EPP.  Creating additional authentication options 
in EPP may result in less security, so it would be good to understand what 
security aspect needs to be fixed prior to creating additional options.



Thanks,

—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 6/13/18, 6:48 PM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Mon, Jun 11, 2018, at 21:57, Gould, James wrote:

> Patrick,

>

>

>

> > JG - Thanks, I'll take a closer look at the PRECIS framework in RFC 
7564

>

> > and 8265.

>

>

>

> Please also look at the SASL framework (RFC4422 and RFC4616 for its

> PLAIN version which is basically what we have currently) : this allows

> to decouple authentication needs to the underlying application/protocol,

> which also address Pieter remark about other ways to authenticate.

>

>

>

> JG - I don’t believe there is any desire to switch from using the

> variant of the PLAIN SASL mechanism [RFC4616] defined in the existing

> EPP RFC [RFC5730].



I do not know. My main point was more around: if we decide to put more 
energy into "securing" EPP better, providing more options than just plain text 
passwords (as asked by Pieter also I think) would be now a good time to think 
about, and if we go towards some "extensibility"  in authentication frameworks, 
why not just build on existing RFCs?



--

  Patrick Mevzek



___

regext mailing list

regext@ietf.org

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


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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Gould, James]

Patrick,

Based on the feedback provided thus far, it looks like setting the minimum to 
the RFC 5730 of 6 with Scott's added language as the way forward.  

Thanks,
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 6/13/18, 6:45 PM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Mon, Jun 11, 2018, at 19:43, Gould, James wrote:
> In thinking about decreasing the minimum from 8 to 1, I have a concern 
> that we're going to support a minimum that is below the existing RFC 
> 5730 of 6 characters.  I believe it would be best for the Login Security 
> Extension to at least support the existing 6 character minimum with the 
> added language that Scott proposed “Servers SHOULD enforce minimum and 
> maximum password length requirements that are appropriate for their 
> operating environment. One example of a guideline for password length 
> policies can be found in  [reference here]".  Scott's 
> language can be added to the Security Considerations section of the 
> draft.
> 
> Let me know if this will work.  

I do not oppose that if this is the consensus but I still see it as 
pointless to provide *any* specific minimum limit here, and I do not see the 
problem with going lower than RFC5730 since this extension is optional and, 
hopefully, if it is used it means the relevant registry has decided to put more 
energy and work around security measures so you could hope they would deal with 
this minimum issue gracefully (that is enforcing something higher than 6, and 
not lower, if they do define the space of characters allowed too).

-- 
  Patrick Mevzek

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


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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Pieter Vandepitte]

I have nothing to add. Just letting know I share the same opinion.

-- 
Pieter Vandepitte
Product Expert
+32 16 28 49 70
www.dnsbelgium.be 
 

 
 

On 14/06/18 00:45, "regext on behalf of Patrick Mevzek" 
 wrote:



On Mon, Jun 11, 2018, at 19:43, Gould, James wrote:
> In thinking about decreasing the minimum from 8 to 1, I have a concern 
> that we're going to support a minimum that is below the existing RFC 
> 5730 of 6 characters.  I believe it would be best for the Login Security 
> Extension to at least support the existing 6 character minimum with the 
> added language that Scott proposed “Servers SHOULD enforce minimum and 
> maximum password length requirements that are appropriate for their 
> operating environment. One example of a guideline for password length 
> policies can be found in  [reference here]".  Scott's 
> language can be added to the Security Considerations section of the 
> draft.
> 
> Let me know if this will work.  

I do not oppose that if this is the consensus but I still see it as 
pointless to provide *any* specific minimum limit here, and I do not see the 
problem with going lower than RFC5730 since this extension is optional and, 
hopefully, if it is used it means the relevant registry has decided to put more 
energy and work around security measures so you could hope they would deal with 
this minimum issue gracefully (that is enforcing something higher than 6, and 
not lower, if they do define the space of characters allowed too).

-- 
  Patrick Mevzek

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


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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Patrick Mevzek]

On Mon, Jun 11, 2018, at 21:57, Gould, James wrote:
> Patrick,
> 
> 
> 
> > JG - Thanks, I'll take a closer look at the PRECIS framework in RFC 7564
> 
> > and 8265.
> 
> 
> 
> Please also look at the SASL framework (RFC4422 and RFC4616 for its 
> PLAIN version which is basically what we have currently) : this allows 
> to decouple authentication needs to the underlying application/protocol, 
> which also address Pieter remark about other ways to authenticate.
> 
> 
> 
> JG - I don’t believe there is any desire to switch from using the 
> variant of the PLAIN SASL mechanism [RFC4616] defined in the existing 
> EPP RFC [RFC5730].

I do not know. My main point was more around: if we decide to put more energy 
into "securing" EPP better, providing more options than just plain text 
passwords (as asked by Pieter also I think) would be now a good time to think 
about, and if we go towards some "extensibility"  in authentication frameworks, 
why not just build on existing RFCs?

-- 
  Patrick Mevzek

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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Patrick Mevzek]

On Mon, Jun 11, 2018, at 19:43, Gould, James wrote:
> In thinking about decreasing the minimum from 8 to 1, I have a concern 
> that we're going to support a minimum that is below the existing RFC 
> 5730 of 6 characters.  I believe it would be best for the Login Security 
> Extension to at least support the existing 6 character minimum with the 
> added language that Scott proposed “Servers SHOULD enforce minimum and 
> maximum password length requirements that are appropriate for their 
> operating environment. One example of a guideline for password length 
> policies can be found in  [reference here]".  Scott's 
> language can be added to the Security Considerations section of the 
> draft.
> 
> Let me know if this will work.  

I do not oppose that if this is the consensus but I still see it as pointless 
to provide *any* specific minimum limit here, and I do not see the problem with 
going lower than RFC5730 since this extension is optional and, hopefully, if it 
is used it means the relevant registry has decided to put more energy and work 
around security measures so you could hope they would deal with this minimum 
issue gracefully (that is enforcing something higher than 6, and not lower, if 
they do define the space of characters allowed too).

-- 
  Patrick Mevzek

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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Marc Groeneweg]

Jim,

It should work for us too. And indeed, the minimum from the current login as 
already accepted as default, so why not hold on to this...

Regards,
Marc

On 11/06/2018, 20:11, "regext on behalf of Hollenbeck, Scott" 
 wrote:

Works for me, Jim.

Scott

> -Original Message-
> From: regext  On Behalf Of Gould, James
> Sent: Monday, June 11, 2018 1:44 PM
> To: Gavin Brown ; Patrick Mevzek
> ; regext@ietf.org
    > Subject: [EXTERNAL] Re: [regext] FW: New Version Notification for draft-
> gould-regext-login-security-00.txt
>
> Hi,
>
> In thinking about decreasing the minimum from 8 to 1, I have a concern
> that we're going to support a minimum that is below the existing RFC 5730
> of 6 characters.  I believe it would be best for the Login Security
> Extension to at least support the existing 6 character minimum with the
> added language that Scott proposed “Servers SHOULD enforce minimum and
> maximum password length requirements that are appropriate for their
> operating environment. One example of a guideline for password length
> policies can be found in  [reference here]".  Scott's language
> can be added to the Security Considerations section of the draft.
>
> Let me know if this will work.
>
> Thanks,
>
> —
>
> JG
>
>
>
> James Gould
> Distinguished Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 6/11/18, 10:00 AM, "Gould, James"  wrote:
>
> Scott & Gavin,
>
> Thanks for weighing in.  I can make Scott's proposed text and schema
> change with the appropriate .  Thanks Patrick for bringing up
> the topic.
>
> —
>
> JG
>
>
>
> James Gould
> Distinguished Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 6/11/18, 9:55 AM, "regext on behalf of Gavin Brown"  boun...@ietf.org on behalf of gavin.br...@centralnic.com> wrote:
>
> +1.
>
> On 11/06/2018 14:49, Patrick Mevzek wrote:
> > On Mon, Jun 11, 2018, at 15:17, Hollenbeck, Scott wrote:
> >> [SAH] Jim, keep in mind that the security guidelines you
> mentioned are
> >> just that – *guidelines* published by a particular entity that
> may or
> >> may not be appropriate for use in different operating
> environments. I’d
> >> be inclined to loosen the Schema to conform to other
> possibilities and
> >> include an informational reference with text along the lines of
> “Servers
> >> SHOULD enforce minimum and maximum password length requirements
> that are
> >> appropriate for their operating environment. One example of a
> guideline
> >> for password length policies can be found in 
> [reference
> >> here]”. A minimum length of 1 would ensure that the field can’t
> be
> >> blank, and the server can check if whatever is provided lines
> up with
> >> expectations for clients.
> >
> > That sound perfect to me. Thanks Scott for the text.
> >
>
> --
> Gavin Brown
> Chief Technology Officer
> CentralNic Group plc (LSE:CNIC)
> Innovative, Reliable and Flexible Registry Services
> for ccTLD, gTLD and private domain name registries
> https://www.centralnic.com/
> +44.7548243029
>
> CentralNic Group plc is a company registered in England and Wales
> with
> company number 8576358. Registered Offices: 35-39 Moorgate,
> London,
> EC2R 6AR.
>
>
>
>
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext


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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Gould, James]

Patrick,



> JG - Thanks, I'll take a closer look at the PRECIS framework in RFC 7564

> and 8265.



Please also look at the SASL framework (RFC4422 and RFC4616 for its PLAIN 
version which is basically what we have currently) : this allows to decouple 
authentication needs to the underlying application/protocol, which also address 
Pieter remark about other ways to authenticate.



JG - I don’t believe there is any desire to switch from using the variant of 
the PLAIN SASL mechanism [RFC4616] defined in the existing EPP RFC [RFC5730].  
SASLprep may still apply in preparing the passwords for setting or comparison.  
I believe that we can incorporate similar language in the Security 
Considerations of RFC 5730 into the Security Considerations section of 
draft-gould-regext-login-security as it relates to the password.  We can 
reference the Passwords section of RFC 8265 that defines the OpaqueString 
PRECIS profile.



Was your concern around the following text in describing the  and 
 elements in draft-gould-regext-login-security?  If so, this is 
simply defining what will happen with the element data by the XML Parser by 
using of the XML schema “token” type.  EPP RFC 5730 uses the “token” type of 
the  and  elements.  Is a different XML schema type desired?  I 
believe removing the leading and trailing whitespace makes sense so the XML 
whitespace is insignificant, but should the contiguous whitespace be collapsed 
to a single space.  The XML schema “normalizedString” and string “types” don’t 
remove the leading or trailing whitespace.  I don’t believe that we’ve run into 
any issues with using the XML schema “token” type in RFC 5730, so my preference 
is to use the same type.


All leading and trailing whitespace is removed, and all internal contiguous 
whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage return), and 
#x20 (space) is replaced with a single #x20 (space).



This would of course imply bigger changes and deeper ones, but for extended 
features also.



I note in passing that there was always a way to extend authorization 
mechanisms in EPP, for the domain:auth element.

I have never seen however any extension proposing there anything different.



JG - I too have not seen an extension of the authorization mechanism in EPP yet 
with the use of ….



—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 6/9/18, 2:26 AM, "Patrick Mevzek"  wrote:



On Wed, Jun 6, 2018, at 15:02, Gould, James wrote:

> JG - I don't view the 8 minimum as a "sacred cow" that would require the

> next iteration of the extension to increase it.



It was 6 before and apparently we "need" to upgrade to 8 now.

I am quite sure than in 5 years we would want to increase 8 to 10 and so 
on, this is purely Moore's law.

So to ease future maintenance I am just saying: remove this arbitrary limit 
in the protocol, since it is a policy decision anyway.



> but I don't believe that it makes sense to not

> at least define the minimum to meet the existing security guidelines.



For me defining a minimum has no sense if you do not define the space of 
possible passwords (which characers) and even various other constraints you may 
place (like no repeating character, or at least one uppercase, etc.)

For the sake of it, imagine the space of allowed characters are digits.

Do you think the security would be increased in any way going from a length 
of 6 to a length of 8 digits?



> JG - Thanks, I'll take a closer look at the PRECIS framework in RFC 7564

> and 8265.



Please also look at the SASL framework (RFC4422 and RFC4616 for its PLAIN 
version which is basically what we have currently) : this allows to decouple 
authentication needs to the underlying application/protocol, which also address 
Pieter remark about other ways to authenticate.



This would of course imply bigger changes and deeper ones, but for extended 
features also.



I note in passing that there was always a way to extend authorization 
mechanisms in EPP, for the domain:auth element.

I have never seen however any extension proposing there anything different.



--

  Patrick Mevzek



___

regext mailing list

regext@ietf.org

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


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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Hollenbeck, Scott]

Works for me, Jim.

Scott

> -Original Message-
> From: regext  On Behalf Of Gould, James
> Sent: Monday, June 11, 2018 1:44 PM
> To: Gavin Brown ; Patrick Mevzek
> ; regext@ietf.org
> Subject: [EXTERNAL] Re: [regext] FW: New Version Notification for draft-
> gould-regext-login-security-00.txt
>
> Hi,
>
> In thinking about decreasing the minimum from 8 to 1, I have a concern
> that we're going to support a minimum that is below the existing RFC 5730
> of 6 characters.  I believe it would be best for the Login Security
> Extension to at least support the existing 6 character minimum with the
> added language that Scott proposed “Servers SHOULD enforce minimum and
> maximum password length requirements that are appropriate for their
> operating environment. One example of a guideline for password length
> policies can be found in  [reference here]".  Scott's language
> can be added to the Security Considerations section of the draft.
>
> Let me know if this will work.
>
> Thanks,
>
> —
>
> JG
>
>
>
> James Gould
> Distinguished Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 6/11/18, 10:00 AM, "Gould, James"  wrote:
>
> Scott & Gavin,
>
> Thanks for weighing in.  I can make Scott's proposed text and schema
> change with the appropriate .  Thanks Patrick for bringing up
> the topic.
>
> —
>
> JG
>
>
>
> James Gould
> Distinguished Engineer
> jgo...@verisign.com
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
> On 6/11/18, 9:55 AM, "regext on behalf of Gavin Brown"  boun...@ietf.org on behalf of gavin.br...@centralnic.com> wrote:
>
> +1.
>
> On 11/06/2018 14:49, Patrick Mevzek wrote:
> > On Mon, Jun 11, 2018, at 15:17, Hollenbeck, Scott wrote:
> >> [SAH] Jim, keep in mind that the security guidelines you
> mentioned are
> >> just that – *guidelines* published by a particular entity that
> may or
> >> may not be appropriate for use in different operating
> environments. I’d
> >> be inclined to loosen the Schema to conform to other
> possibilities and
> >> include an informational reference with text along the lines of
> “Servers
> >> SHOULD enforce minimum and maximum password length requirements
> that are
> >> appropriate for their operating environment. One example of a
> guideline
> >> for password length policies can be found in 
> [reference
> >> here]”. A minimum length of 1 would ensure that the field can’t
> be
> >> blank, and the server can check if whatever is provided lines
> up with
> >> expectations for clients.
> >
> > That sound perfect to me. Thanks Scott for the text.
> >
>
> --
> Gavin Brown
> Chief Technology Officer
> CentralNic Group plc (LSE:CNIC)
> Innovative, Reliable and Flexible Registry Services
> for ccTLD, gTLD and private domain name registries
> https://www.centralnic.com/
> +44.7548243029
>
> CentralNic Group plc is a company registered in England and Wales
> with
> company number 8576358. Registered Offices: 35-39 Moorgate,
> London,
> EC2R 6AR.
>
>
>
>
>
> ___
> regext mailing list
> regext@ietf.org
> https://www.ietf.org/mailman/listinfo/regext
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Gould, James]

Hi,

In thinking about decreasing the minimum from 8 to 1, I have a concern that 
we're going to support a minimum that is below the existing RFC 5730 of 6 
characters.  I believe it would be best for the Login Security Extension to at 
least support the existing 6 character minimum with the added language that 
Scott proposed “Servers SHOULD enforce minimum and maximum password length 
requirements that are appropriate for their operating environment. One example 
of a guideline for password length policies can be found in  
[reference here]".  Scott's language can be added to the Security 
Considerations section of the draft.

Let me know if this will work.  

Thanks,
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 6/11/18, 10:00 AM, "Gould, James"  wrote:

Scott & Gavin,

Thanks for weighing in.  I can make Scott's proposed text and schema change 
with the appropriate .  Thanks Patrick for bringing up the topic.  
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 6/11/18, 9:55 AM, "regext on behalf of Gavin Brown" 
 wrote:

+1.

On 11/06/2018 14:49, Patrick Mevzek wrote:
> On Mon, Jun 11, 2018, at 15:17, Hollenbeck, Scott wrote:
>> [SAH] Jim, keep in mind that the security guidelines you mentioned 
are 
>> just that – *guidelines* published by a particular entity that may 
or 
>> may not be appropriate for use in different operating environments. 
I’d 
>> be inclined to loosen the Schema to conform to other possibilities 
and 
>> include an informational reference with text along the lines of 
“Servers 
>> SHOULD enforce minimum and maximum password length requirements that 
are 
>> appropriate for their operating environment. One example of a 
guideline 
>> for password length policies can be found in  [reference 
>> here]”. A minimum length of 1 would ensure that the field can’t be 
>> blank, and the server can check if whatever is provided lines up 
with 
>> expectations for clients.
> 
> That sound perfect to me. Thanks Scott for the text.
> 

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.





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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Gould, James]

Scott & Gavin,

Thanks for weighing in.  I can make Scott's proposed text and schema change 
with the appropriate .  Thanks Patrick for bringing up the topic.  
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 6/11/18, 9:55 AM, "regext on behalf of Gavin Brown" 
 wrote:

+1.

On 11/06/2018 14:49, Patrick Mevzek wrote:
> On Mon, Jun 11, 2018, at 15:17, Hollenbeck, Scott wrote:
>> [SAH] Jim, keep in mind that the security guidelines you mentioned are 
>> just that – *guidelines* published by a particular entity that may or 
>> may not be appropriate for use in different operating environments. I’d 
>> be inclined to loosen the Schema to conform to other possibilities and 
>> include an informational reference with text along the lines of “Servers 
>> SHOULD enforce minimum and maximum password length requirements that are 
>> appropriate for their operating environment. One example of a guideline 
>> for password length policies can be found in  [reference 
>> here]”. A minimum length of 1 would ensure that the field can’t be 
>> blank, and the server can check if whatever is provided lines up with 
>> expectations for clients.
> 
> That sound perfect to me. Thanks Scott for the text.
> 

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Gavin Brown]

+1.

On 11/06/2018 14:49, Patrick Mevzek wrote:
> On Mon, Jun 11, 2018, at 15:17, Hollenbeck, Scott wrote:
>> [SAH] Jim, keep in mind that the security guidelines you mentioned are 
>> just that – *guidelines* published by a particular entity that may or 
>> may not be appropriate for use in different operating environments. I’d 
>> be inclined to loosen the Schema to conform to other possibilities and 
>> include an informational reference with text along the lines of “Servers 
>> SHOULD enforce minimum and maximum password length requirements that are 
>> appropriate for their operating environment. One example of a guideline 
>> for password length policies can be found in  [reference 
>> here]”. A minimum length of 1 would ensure that the field can’t be 
>> blank, and the server can check if whatever is provided lines up with 
>> expectations for clients.
> 
> That sound perfect to me. Thanks Scott for the text.
> 

-- 
Gavin Brown
Chief Technology Officer
CentralNic Group plc (LSE:CNIC)
Innovative, Reliable and Flexible Registry Services
for ccTLD, gTLD and private domain name registries
https://www.centralnic.com/
+44.7548243029

CentralNic Group plc is a company registered in England and Wales with
company number 8576358. Registered Offices: 35-39 Moorgate, London,
EC2R 6AR.



signature.asc
Description: OpenPGP digital signature
___
regext mailing list
regext@ietf.org
https://www.ietf.org/mailman/listinfo/regext

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Patrick Mevzek]

On Mon, Jun 11, 2018, at 15:17, Hollenbeck, Scott wrote:
> [SAH] Jim, keep in mind that the security guidelines you mentioned are 
> just that – *guidelines* published by a particular entity that may or 
> may not be appropriate for use in different operating environments. I’d 
> be inclined to loosen the Schema to conform to other possibilities and 
> include an informational reference with text along the lines of “Servers 
> SHOULD enforce minimum and maximum password length requirements that are 
> appropriate for their operating environment. One example of a guideline 
> for password length policies can be found in  [reference 
> here]”. A minimum length of 1 would ensure that the field can’t be 
> blank, and the server can check if whatever is provided lines up with 
> expectations for clients.

That sound perfect to me. Thanks Scott for the text.

-- 
  Patrick Mevzek

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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Hollenbeck, Scott]

From: regext  On Behalf Of Gould, James
Sent: Monday, June 11, 2018 9:01 AM
To: Patrick Mevzek ; regext@ietf.org
Subject: [EXTERNAL] Re: [regext] FW: New Version Notification for 
draft-gould-regext-login-security-00.txt



It was 6 before and apparently we "need" to upgrade to 8 now.

I am quite sure than in 5 years we would want to increase 8 to 10 and so on, 
this is purely Moore's law.

So to ease future maintenance I am just saying: remove this arbitrary limit in 
the protocol, since it is a policy decision anyway.



Are there any other thoughts on inclusion of a minimum of 8 characters for the 
password in draft-gould-regext-login-security versus specifying no minimum and 
leaving the minimum up to server policy?  My preference is to meet the existing 
security guidelines by specifying the minimum of 8 characters and Patrick’s 
preference is to remove the minimum.  Any other thoughts on this is greatly 
appreciated.



[SAH] Jim, keep in mind that the security guidelines you mentioned are just 
that – *guidelines* published by a particular entity that may or may not be 
appropriate for use in different operating environments. I’d be inclined to 
loosen the Schema to conform to other possibilities and include an 
informational reference with text along the lines of “Servers SHOULD enforce 
minimum and maximum password length requirements that are appropriate for their 
operating environment. One example of a guideline for password length policies 
can be found in  [reference here]”. A minimum length of 1 would 
ensure that the field can’t be blank, and the server can check if whatever is 
provided lines up with expectations for clients.



Scott

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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Gould, James]

It was 6 before and apparently we "need" to upgrade to 8 now.

I am quite sure than in 5 years we would want to increase 8 to 10 and so on, 
this is purely Moore's law.

So to ease future maintenance I am just saying: remove this arbitrary limit in 
the protocol, since it is a policy decision anyway.



Are there any other thoughts on inclusion of a minimum of 8 characters for the 
password in draft-gould-regext-login-security versus specifying no minimum and 
leaving the minimum up to server policy?  My preference is to meet the existing 
security guidelines by specifying the minimum of 8 characters and Patrick’s 
preference is to remove the minimum.  Any other thoughts on this is greatly 
appreciated.



Thanks,



—

JG







James Gould

Distinguished Engineer

jgo...@verisign.com



703-948-3271

12061 Bluemont Way

Reston, VA 20190



Verisign.com 



On 6/9/18, 2:26 AM, "Patrick Mevzek"  wrote:



On Wed, Jun 6, 2018, at 15:02, Gould, James wrote:

> JG - I don't view the 8 minimum as a "sacred cow" that would require the

> next iteration of the extension to increase it.



It was 6 before and apparently we "need" to upgrade to 8 now.

I am quite sure than in 5 years we would want to increase 8 to 10 and so 
on, this is purely Moore's law.

So to ease future maintenance I am just saying: remove this arbitrary limit 
in the protocol, since it is a policy decision anyway.



> but I don't believe that it makes sense to not

> at least define the minimum to meet the existing security guidelines.



For me defining a minimum has no sense if you do not define the space of 
possible passwords (which characers) and even various other constraints you may 
place (like no repeating character, or at least one uppercase, etc.)

For the sake of it, imagine the space of allowed characters are digits.

Do you think the security would be increased in any way going from a length 
of 6 to a length of 8 digits?



> JG - Thanks, I'll take a closer look at the PRECIS framework in RFC 7564

> and 8265.



Please also look at the SASL framework (RFC4422 and RFC4616 for its PLAIN 
version which is basically what we have currently) : this allows to decouple 
authentication needs to the underlying application/protocol, which also address 
Pieter remark about other ways to authenticate.



This would of course imply bigger changes and deeper ones, but for extended 
features also.



I note in passing that there was always a way to extend authorization 
mechanisms in EPP, for the domain:auth element.

I have never seen however any extension proposing there anything different.



--

  Patrick Mevzek



___

regext mailing list

regext@ietf.org

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


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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Patrick Mevzek]

On Wed, Jun 6, 2018, at 15:02, Gould, James wrote:
> JG - I don't view the 8 minimum as a "sacred cow" that would require the 
> next iteration of the extension to increase it. 

It was 6 before and apparently we "need" to upgrade to 8 now.
I am quite sure than in 5 years we would want to increase 8 to 10 and so on, 
this is purely Moore's law.
So to ease future maintenance I am just saying: remove this arbitrary limit in 
the protocol, since it is a policy decision anyway.

> but I don't believe that it makes sense to not 
> at least define the minimum to meet the existing security guidelines.  

For me defining a minimum has no sense if you do not define the space of 
possible passwords (which characers) and even various other constraints you may 
place (like no repeating character, or at least one uppercase, etc.)
For the sake of it, imagine the space of allowed characters are digits.
Do you think the security would be increased in any way going from a length of 
6 to a length of 8 digits?
 
> JG - Thanks, I'll take a closer look at the PRECIS framework in RFC 7564 
> and 8265.

Please also look at the SASL framework (RFC4422 and RFC4616 for its PLAIN 
version which is basically what we have currently) : this allows to decouple 
authentication needs to the underlying application/protocol, which also address 
Pieter remark about other ways to authenticate.

This would of course imply bigger changes and deeper ones, but for extended 
features also.

I note in passing that there was always a way to extend authorization 
mechanisms in EPP, for the domain:auth element.
I have never seen however any extension proposing there anything different.

-- 
  Patrick Mevzek

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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Gould, James]

Patrick, 

My comments are embedded below.
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 6/6/18, 3:07 AM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Tue, Jun 5, 2018, at 17:11, Gould, James wrote:
> JG - The reason for a '[LOGIN-SECURITY]' constant value in RFC 5730  

[..]

Yes, but my comment was both to propose other values than this string and 
even alternate mechanisms. Please have a look and let me know.

> There may be a better constant value to use or another 
> mechanism that is compliant with RFC 5730, while allowing for overriding 
> the password value in the extension.

This is indeed the subject on the table.

> - for loginSec:pw/loginSec:newPw I am not a fan of specifying 
> minimum length, because if you remove all maximum length constraint in 
> the schema for the maximum, by symmetry I would do the same for the 
> minimum, leaving both to pure policy choices by the server (the 
> "sensible"  minimum depends of course on the number of different 
> characters allowed, it would not be the same value when accepting only 
> ASCII or when accepting "any" Unicode characters
>   
> JG - I don't believe that the security would be enhanced by removing the 
> minimum length.  RFC 5730 had a minimum of 6 characters and I bumped it 
> up to a minimum of 8 characters to match current password security 
> guidelines.  NIST defines the minimum length as 8 characters. 

I never said the security would be "enhanced" I am saying that if part of 
the goal of the new extension is to remove previous artifical limits on length, 
it might as well let the policy decide what good vales are, instead of the 
protocol.
Defining a minimum length without defining the space of characters allowed 
nor miscelleanous rules regarding complexity seems defeating the purpose, you 
just enshrine some arbitrary numbers as sacred cows. And the next iteration of 
the extension will again need to lift the value.

JG - I don't view the 8 minimum as a "sacred cow" that would require the next 
iteration of the extension to increase it.  Back in the early 2000's, the 
security guidelines specified the use of a password with a minimum length of 6. 
 Now the guidelines specify the minimum length of 8.  Server policy can 
certainly define a higher minimum than what is defined in the protocol, but I 
don't believe that it makes sense to not at least define the minimum to meet 
the existing security guidelines.  Inclusion of a maximum in the protocol needs 
to be removed to handle future security guidelines that does not require an 
update to the protocol.  I don't foresee the security guidelines defining a 
shorter minimum, so we should be safe in defining a minimum based on the 
current security guidelines that can be increased based on policy.  

   
> - I would also not put anything here related to what characters are 
> allowed or not. I would instead defer to the PRECIS framework (RFC7564) 
> and more specifically section 4 of RFC8265. At least as a base, using 
> OpaqueString and then building one more constrained on top of it if it 
> is really deemed important
> (passwords here are typically not seen nor managed by humans, so I 
> think they need less strict rules than when handled by humans, and I see 
> no problems per se with spaces... I have seen far more trouble when 
> people try to use < or & in a password and forgetting to encode it as 
> those are specific characters in an XML streams).
> 
> I know that RFC5730 does the same thing, but it was written before 
PRECIS.
> So now I think we should instead build on it.
> 
> JG - The rules around the leading / trailing whitespace and the 
> contiguous whitespace is based on the selection of the XML schema 
> "token" type.  We could consider changing the type, but that is the type 
> defined in RFC 5730.  The login security extension simply removes the 
> maximum length constraint and increases the minimum length constraint 
> from 6 characters to 8 characters to meet current security guidelines.
 

Please have a look again at what I wrote and the details about PRECIS.
I still think that this is not core EPP and hence we should defer to other 
RFCs dealing with passwords for recommendations instead of trying to invent new 
ones.
This has nothing to do with the XML schema type.

And I am still not convinced that whitespaces are a problem here (again, 
because the password is entered by a program and not by a human), but this is a 
bikeshedding point.

JG - Thanks, I'll take a closer look at the PRECIS framework in RFC 7564 and 
8265.

-- 
  Patrick Mevzek

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Gould, James]

Patrick,

Thanks, I include my comments embedded below.
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 6/6/18, 2:55 AM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Tue, Jun 5, 2018, at 17:13, Gould, James wrote:

> 
> On Tue, Jun 5, 2018, at 09:26, Pieter Vandepitte wrote:
> > I follow the concerns of Patrick,
> > 
> > I'm neither a fan of the [LOGIN-SECURITY]. Isn't it enough to 
specify 
> > that a server MUST ignore the value of  if the loginSec 
extension is 
> > used?
> 
> That could be a solution too, and would work for further versions. 
> 
> JG - I included the basis for the use of the '[LOGIN-SECURITY]' constant 
> value in my original response, which I copied below for quick reference:

[..]

> Any ideas with a better constant value or mechanism is greatly 
appreciated.  

Please see my other email where I discuss this point and I provide other 
ideas
and also alternative mechanisms.

JG - Thanks, I'll take a closer look at the other ideas and alternative 
mechanisms that you provided in the other email.


> There is already a VeriSign EPP extension for 2 factors auth, I do 
> not find it online anymore but I implemented it and it was for 
> namespaces:
> http://www.verisign.com/epp/authExt-1.0
> 'http://www.verisign.com/epp/authSession-1.0
> but it was more for domain:update operations.
>  
> JG - The 2 factor auth extensions (authSession and authExt) were not 
> targeted for registrar login, but meant to be used to protect objects 
> (e.g., domains) using a registrant second factor (OTP).

Yes, I know.
The point was to say there are alternate mechanisms and like Pieter 
suggested, if we are up to "beefing up" handling of login in EPP we might as 
well take the opportunity to enlarge the scope and take into account other 
mechanisms... like 2FA.

JG - EPP already uses a second factor with the use of the client certificate 
with two-way SSL.  Is there the need to consider another second factor for a 
system-to-system protocol like EPP?  Is there a driving reason and benefit in 
considering additional authentication methods for inclusion in the Login 
Security Extension?

> These 
> extensions were never published.  

They were at some point (and they where implemented) and they are still 
available on various places such as
http://www.freepatentsonline.com/y2012/0174198.html

JG - I don't remember creating formal extension specifications or publishing 
them.   


-- 
  Patrick Mevzek

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


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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Patrick Mevzek]

On Tue, Jun 5, 2018, at 17:11, Gould, James wrote:
> JG - The reason for a '[LOGIN-SECURITY]' constant value in RFC 5730  

[..]

Yes, but my comment was both to propose other values than this string and even 
alternate mechanisms. Please have a look and let me know.

> There may be a better constant value to use or another 
> mechanism that is compliant with RFC 5730, while allowing for overriding 
> the password value in the extension.

This is indeed the subject on the table.

> - for loginSec:pw/loginSec:newPw I am not a fan of specifying 
> minimum length, because if you remove all maximum length constraint in 
> the schema for the maximum, by symmetry I would do the same for the 
> minimum, leaving both to pure policy choices by the server (the 
> "sensible"  minimum depends of course on the number of different 
> characters allowed, it would not be the same value when accepting only 
> ASCII or when accepting "any" Unicode characters
>   
> JG - I don't believe that the security would be enhanced by removing the 
> minimum length.  RFC 5730 had a minimum of 6 characters and I bumped it 
> up to a minimum of 8 characters to match current password security 
> guidelines.  NIST defines the minimum length as 8 characters. 

I never said the security would be "enhanced" I am saying that if part of the 
goal of the new extension is to remove previous artifical limits on length, it 
might as well let the policy decide what good vales are, instead of the 
protocol.
Defining a minimum length without defining the space of characters allowed nor 
miscelleanous rules regarding complexity seems defeating the purpose, you just 
enshrine some arbitrary numbers as sacred cows. And the next iteration of the 
extension will again need to lift the value.
   
> - I would also not put anything here related to what characters are 
> allowed or not. I would instead defer to the PRECIS framework (RFC7564) 
> and more specifically section 4 of RFC8265. At least as a base, using 
> OpaqueString and then building one more constrained on top of it if it 
> is really deemed important
> (passwords here are typically not seen nor managed by humans, so I 
> think they need less strict rules than when handled by humans, and I see 
> no problems per se with spaces... I have seen far more trouble when 
> people try to use < or & in a password and forgetting to encode it as 
> those are specific characters in an XML streams).
> 
> I know that RFC5730 does the same thing, but it was written before PRECIS.
> So now I think we should instead build on it.
> 
> JG - The rules around the leading / trailing whitespace and the 
> contiguous whitespace is based on the selection of the XML schema 
> "token" type.  We could consider changing the type, but that is the type 
> defined in RFC 5730.  The login security extension simply removes the 
> maximum length constraint and increases the minimum length constraint 
> from 6 characters to 8 characters to meet current security guidelines. 

Please have a look again at what I wrote and the details about PRECIS.
I still think that this is not core EPP and hence we should defer to other RFCs 
dealing with passwords for recommendations instead of trying to invent new ones.
This has nothing to do with the XML schema type.

And I am still not convinced that whitespaces are a problem here (again, 
because the password is entered by a program and not by a human), but this is a 
bikeshedding point.

-- 
  Patrick Mevzek

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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Gould, James]

Patrick and Pieter,

Thanks for your review of the extension and your feedback.  I include comments 
to the feedback below.
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 6/5/18, 9:30 AM, "regext on behalf of Patrick Mevzek" 
 wrote:



On Tue, Jun 5, 2018, at 09:26, Pieter Vandepitte wrote:
> I follow the concerns of Patrick,
> 
> I'm neither a fan of the [LOGIN-SECURITY]. Isn't it enough to specify 
> that a server MUST ignore the value of  if the loginSec extension is 
> used?

That could be a solution too, and would work for further versions. 

JG - I included the basis for the use of the '[LOGIN-SECURITY]' constant value 
in my original response, which I copied below for quick reference:

The reason for a '[LOGIN-SECURITY]' constant value in RFC 5730  is because 
the  element is required and must be between 6 and 16 characters, so it 
must be populated with something.  On the server-side, the  value 
is looked at only if the '[LOGIN-SECURITY]' constant value is specified in the 
 element.  This means that the existing  element is never ignored but 
simply used to explicitly refer to the  element with the use of a 
pre-defined constant value.  There may be a better constant value to use or 
another mechanism that is compliant with RFC 5730, while allowing for 
overriding the password value in the extension.  The same approach is used for 
the RFC 5730  element, and the related  element.  Use of 
the constant password value and the login security extension maintains backward 
compatibility, maintains compliance with RFC 5730, and enables an incremental 
switch to use longer passwords with the login security extension (e.g., short 
password with  element and long new password via the  
element).  The server would need to disallow the password to be set to 
'[LOGIN-SECURITY]'  to avoid conflict; otherwise the client would need to use 
the '[LOGIN-SECURITY]' value with the RFC 5730  element and with the 
 element to authenticate.  

Any ideas with a better constant value or mechanism is greatly appreciated.  

> I don't know if I overlooked it, but it seems that there's only support 
> for password based login and provisioning. Do you plan to support other 
> things like digest authentication?

I agree that it could be useful and I forgot about that, it could be a good 
idea to make something more generic at the same time, to handle other kind of 
authentications.

There is already a VeriSign EPP extension for 2 factors auth, I do not find 
it online anymore but I implemented it and it was for namespaces:
http://www.verisign.com/epp/authExt-1.0
'http://www.verisign.com/epp/authSession-1.0
but it was more for domain:update operations.
 
JG - The 2 factor auth extensions (authSession and authExt) were not targeted 
for registrar login, but meant to be used to protect objects (e.g., domains) 
using a registrant second factor (OTP).  These extensions were never published. 
 

   
-- 
  Patrick Mevzek

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


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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Gould, James]

Patrick, 

Thanks for your review of the extension and your feedback.  I include comments 
to the feedback below.
  
—
 
JG



James Gould
Distinguished Engineer
jgo...@verisign.com

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

Verisign.com  

On 6/5/18, 1:32 AM, "regext on behalf of Patrick Mevzek" 
 wrote:

On Mon, Jun 4, 2018, at 22:30, Gould, James wrote:
> The Login Security Extension (draft-gould-regext-login-security) was 
> posted 
> (https://datatracker.ietf.org/doc/draft-gould-regext-login-security/) 

Thanks James, this is nice.

Some comments before really trying to implement it:

- I am not a huge fan of the [LOGIN-SECURITY] token, but I see no good 
alternatives. Specifically, this variant forbids any later revision of the 
specification. So I would either argue for the shortname, loginSec-1.0, so that 
at least it will be backwards compatible or, to be bolder, use RFC when 
 will be known...
Or to want to avoid collisions at all cost, I would either go towards 
something like U+001A (SUBSTITUTE) or U+001B (ESCAPE) repeated 16 times.

Or a completely different route would be to use the XML ID/IDREF mechanism.
I am not 100% sure but maybe the current  could have an xml:IDREF 
attribute with a path pointing to the new loginSec:pw node which would have the 
corresponding xml:ID attribute?
  
JG - The reason for a '[LOGIN-SECURITY]' constant value in RFC 5730  is 
because the  element is required and must be between 6 and 16 characters, 
so it must be populated with something.  On the server-side, the  
value is looked at only if the '[LOGIN-SECURITY]' constant value is specified 
in the  element.  This means that the existing  element is never 
ignored but simply used to explicitly refer to the  element with 
the use of a pre-defined constant value.  There may be a better constant value 
to use or another mechanism that is compliant with RFC 5730, while allowing for 
overriding the password value in the extension.  The same approach is used for 
the RFC 5730  element, and the related  element.  Use of 
the constant password value and the login security extension maintains backward 
compatibility, maintains compliance with RFC 5730, and enables an incremental 
switch to use longer passwords with the login security extension (e.g., short 
password with  element and long new password via the  
element).  The server would need to disallow the password to be set to 
'[LOGIN-SECURITY]'  to avoid conflict; otherwise the client would need to use 
the '[LOGIN-SECURITY]' value with the RFC 5730  element and with the 
 element to authenticate.  

  
- for loginSec:pw/loginSec:newPw I am not a fan of specifying minimum 
length, because if you remove all maximum length constraint in the schema for 
the maximum, by symmetry I would do the same for the minimum, leaving both to 
pure policy choices by the server (the "sensible"  minimum depends of course on 
the number of different characters allowed, it would not be the same value when 
accepting only ASCII or when accepting "any" Unicode characters
  
JG - I don't believe that the security would be enhanced by removing the 
minimum length.  RFC 5730 had a minimum of 6 characters and I bumped it up to a 
minimum of 8 characters to match current password security guidelines.  NIST 
defines the minimum length as 8 characters. 
  
- I would also not put anything here related to what characters are allowed 
or not. I would instead defer to the PRECIS framework (RFC7564) and more 
specifically section 4 of RFC8265. At least as a base, using OpaqueString and 
then building one more constrained on top of it if it is really deemed important
(passwords here are typically not seen nor managed by humans, so I think 
they need less strict rules than when handled by humans, and I see no problems 
per se with spaces... I have seen far more trouble when people try to use < or 
& in a password and forgetting to encode it as those are specific characters in 
an XML streams).

I know that RFC5730 does the same thing, but it was written before PRECIS.
So now I think we should instead build on it.

JG - The rules around the leading / trailing whitespace and the contiguous 
whitespace is based on the selection of the XML schema "token" type.  We could 
consider changing the type, but that is the type defined in RFC 5730.  The 
login security extension simply removes the maximum length constraint and 
increases the minimum length constraint from 6 characters to 8 characters to 
meet current security guidelines. 


-- 
  Patrick Mevzek

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


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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Patrick Mevzek]

On Tue, Jun 5, 2018, at 09:26, Pieter Vandepitte wrote:
> I follow the concerns of Patrick,
> 
> I'm neither a fan of the [LOGIN-SECURITY]. Isn't it enough to specify 
> that a server MUST ignore the value of  if the loginSec extension is 
> used?

That could be a solution too, and would work for further versions. 

> I don't know if I overlooked it, but it seems that there's only support 
> for password based login and provisioning. Do you plan to support other 
> things like digest authentication?

I agree that it could be useful and I forgot about that, it could be a good 
idea to make something more generic at the same time, to handle other kind of 
authentications.

There is already a VeriSign EPP extension for 2 factors auth, I do not find it 
online anymore but I implemented it and it was for namespaces:
http://www.verisign.com/epp/authExt-1.0
'http://www.verisign.com/epp/authSession-1.0
but it was more for domain:update operations.

-- 
  Patrick Mevzek

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

Re: [regext] FW: New Version Notification for draft-gould-regext-login-security-00.txt

[Pieter Vandepitte]

I follow the concerns of Patrick,

I'm neither a fan of the [LOGIN-SECURITY]. Isn't it enough to specify that a 
server MUST ignore the value of  if the loginSec extension is used?

I don't know if I overlooked it, but it seems that there's only support for 
password based login and provisioning. Do you plan to support other things like 
digest authentication?

Kind regards

Pieter


On 05/06/18 07:32, "regext on behalf of Patrick Mevzek" 
 wrote:

On Mon, Jun 4, 2018, at 22:30, Gould, James wrote:
> The Login Security Extension (draft-gould-regext-login-security) was 
> posted 
> (https://datatracker.ietf.org/doc/draft-gould-regext-login-security/) 

Thanks James, this is nice.

Some comments before really trying to implement it:

- I am not a huge fan of the [LOGIN-SECURITY] token, but I see no good 
alternatives. Specifically, this variant forbids any later revision of the 
specification. So I would either argue for the shortname, loginSec-1.0, so that 
at least it will be backwards compatible or, to be bolder, use RFC when 
 will be known...
Or to want to avoid collisions at all cost, I would either go towards 
something like U+001A (SUBSTITUTE) or U+001B (ESCAPE) repeated 16 times.

Or a completely different route would be to use the XML ID/IDREF mechanism.
I am not 100% sure but maybe the current  could have an xml:IDREF 
attribute with a path pointing to the new loginSec:pw node which would have the 
corresponding xml:ID attribute?

- for loginSec:pw/loginSec:newPw I am not a fan of specifying minimum 
length, because if you remove all maximum length constraint in the schema for 
the maximum, by symmetry I would do the same for the minimum, leaving both to 
pure policy choices by the server (the "sensible"  minimum depends of course on 
the number of different characters allowed, it would not be the same value when 
accepting only ASCII or when accepting "any" Unicode characters

- I would also not put anything here related to what characters are allowed 
or not. I would instead defer to the PRECIS framework (RFC7564) and more 
specifically section 4 of RFC8265. At least as a base, using OpaqueString and 
then building one more constrained on top of it if it is really deemed important
(passwords here are typically not seen nor managed by humans, so I think 
they need less strict rules than when handled by humans, and I see no problems 
per se with spaces... I have seen far more trouble when people try to use < or 
& in a password and forgetting to encode it as those are specific characters in 
an XML streams).

I know that RFC5730 does the same thing, but it was written before PRECIS.
So now I think we should instead build on it.

-- 
  Patrick Mevzek

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


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