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

From: "Gould, James" <[email-masked]>
Date: Mon, 4 Jun 2018 20:30:20 +0000

The Login Security Extension (draft-gould-regext-login-security) was posted (https://datatracker.ietf.org/doc/draft-gould-regext-login-security/) that enhances the security of the EPP sessions with the following:

  1.  Support for passwords (current and new) beyond the RFC 5730 limit of 16 characters in an extension to the login command;
  2.  Support for the server to return security warnings and errors in an extension to the login response (password expiry, certificate expiry, insecure cipher, insecure TLS, failed login statistics, etc.);
  3.  Support the optional passing of the client’s user agent in an extension to the login command for the server to identify functional or security constraints, current security issues, and potential future functional or security issues for the client.

Please review and provide any feedback privately or on the list.  I would like a slot in the REGEXT WG meeting to introduce and discuss this new extension.

Thanks,

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

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

On 6/4/18, 4:18 PM, "[email-masked]" <[email-masked]> wrote:

    A new version of I-D, draft-gould-regext-login-security-00.txt

    has been successfully submitted by James Gould and posted to the

    IETF repository.

    Name:                              draft-gould-regext-login-security

    Revision:         00

    Title:                  Login Security Extension for the Extensible Provisioning Protocol (EPP)

    Document date:           2018-06-04

    Group:                             Individual Submission

    Pages:                              18

    URL:            https://www.ietf.org/internet-drafts/draft-gould-regext-login-security-00.txt

    Status:         https://datatracker.ietf.org/doc/draft-gould-regext-login-security/

    Htmlized:       https://tools.ietf.org/html/draft-gould-regext-login-security-00

    Htmlized:       https://datatracker.ietf.org/doc/html/draft-gould-regext-login-security

    Abstract:

       The Extensible Provisioning Protocol (EPP) includes a client

       authentication scheme that is based on a user identifier and

       password.  The structure of the password field is defined by an XML

       Schema data type that specifies minimum and maximum password length

       values, but there are no other provisions for password management

       other than changing the password.  This document describes an EPP

       extension that allows longer passwords to be created and adds

       additional security features to the EPP login command and response.

    Please note that it may take a couple of minutes from the time of submission

    until the htmlized version and diff are available at tools.ietf.org.

    The IETF Secretariat

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 05 Jun 2018 07:32:32 +0200

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 RFCXXXX when XXXX 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 <pw> 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

---

From: Pieter Vandepitte <[email-masked]>
Date: Tue, 5 Jun 2018 07:26:17 +0000

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 <pw> 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" <[email-masked] on behalf of [email-masked]> wrote:

    

    

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

---

From: Patrick Mevzek <[email-masked]>
Date: Tue, 05 Jun 2018 15:29:50 +0200

On Tue, Jun 5, 2018, at 09:26, Pieter Vandepitte wrote:
> I'm neither a fan of the [LOGIN-SECURITY]. Isn't it enough to specify 
> that a server MUST ignore the value of <pw> 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

---

From: "Gould, James" <[email-masked]>
Date: Tue, 5 Jun 2018 15:11:15 +0000

Patrick, 

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

James Gould
Distinguished Engineer
[email-masked]

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

On 6/5/18, 1:32 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

  
JG - The reason for a '[LOGIN-SECURITY]' constant value in RFC 5730 <pw> is because the <pw> element is required and must be between 6 and 16 characters, so it must be populated with something.  On the server-side, the <loginSec:pw> value is looked at only if the '[LOGIN-SECURITY]' constant value is specified in the <pw> element.  This means that the existing <pw> element is never ignored but simply used to explicitly refer to the <loginSec:pw> 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 <newPw> element, and the related <loginSec:newPw> 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 <pw> element and long new password via the <loginSec:newPw> 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 <pw> element and with the <loginSec:pw> element to authenticate.  

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.     

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

---

From: "Gould, James" <[email-masked]>
Date: Tue, 5 Jun 2018 15:13:25 +0000

Patrick and Pieter,

—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 6/5/18, 9:30 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    

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 <pw> is because the <pw> element is required and must be between 6 and 16 characters, so it must be populated with something.  On the server-side, the <loginSec:pw> value is looked at only if the '[LOGIN-SECURITY]' constant value is specified in the <pw> element.  This means that the existing <pw> element is never ignored but simply used to explicitly refer to the <loginSec:pw> 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 <newPw> element, and the related <loginSec:newPw> 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 <pw> element and long new password via the <loginSec:newPw> 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 <pw> element and with the <loginSec:pw> element to authenticate.  

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

    
 
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

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 06 Jun 2018 08:54:49 +0200

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

> 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.

>     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:
> 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.

> 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

-- 
  Patrick Mevzek

---

From: Patrick Mevzek <[email-masked]>
Date: Wed, 06 Jun 2018 09:07:21 +0200

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

[..]

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).
>     
> 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

---

From: "Gould, James" <[email-masked]>
Date: Wed, 6 Jun 2018 12:49:36 +0000

Patrick,

Thanks, I include my comments embedded below.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 6/6/18, 2:55 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    [..]

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

    Yes, I know.

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?    

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

    -- 
      Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Wed, 6 Jun 2018 13:02:53 +0000

Patrick, 

My comments are embedded below.
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 6/6/18, 3:07 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> 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.  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.  

    

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

---

From: Patrick Mevzek <[email-masked]>
Date: Sat, 09 Jun 2018 08:25:55 +0200

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 

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

---

From: "Gould, James" <[email-masked]>
Date: Mon, 11 Jun 2018 13:00:37 +0000

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

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 6/9/18, 2:26 AM, "Patrick Mevzek" <[email-masked]> wrote:

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

    > and 8265.

    --

      Patrick Mevzek

    regext mailing list

    [email-masked]

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 11 Jun 2018 13:17:12 +0000

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

[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 <blah blah> [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

---

From: Patrick Mevzek <[email-masked]>
Date: Mon, 11 Jun 2018 15:49:54 +0200

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 <blah blah> [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

---

From: Gavin Brown <[email-masked]>
Date: Mon, 11 Jun 2018 14:54:44 +0100

+1.

-- 
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.

---

From: "Gould, James" <[email-masked]>
Date: Mon, 11 Jun 2018 14:00:09 +0000

Scott & Gavin,

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

James Gould
Distinguished Engineer
[email-masked]

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

On 6/11/18, 9:55 AM, "regext on behalf of Gavin Brown" <[email-masked] on behalf of [email-masked]> wrote:

    +1.

---

From: "Gould, James" <[email-masked]>
Date: Mon, 11 Jun 2018 17:43:32 +0000

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

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

On 6/11/18, 10:00 AM, "Gould, James" <[email-masked]> wrote:

    Scott & Gavin,

    —
     
    JG

    James Gould
    Distinguished Engineer
    [email-masked]
    
    703-948-3271
    12061 Bluemont Way
    Reston, VA 20190

    
        +1.

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 11 Jun 2018 18:10:46 +0000

Works for me, Jim.

Scott

> -----Original Message-----
> Sent: Monday, June 11, 2018 1:44 PM
> To: Gavin Brown <[email-masked]>; Patrick Mevzek
> <[email-masked]>; [email-masked]
> 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 <blah blah> [reference here]".  Scott's language
> can be added to the Security Considerations section of the draft.
>
>     Thanks for weighing in.  I can make Scott's proposed text and schema
> change with the appropriate <blah blah>.  Thanks Patrick for bringing up
> the topic.
>
>     —
>
>     JG
>
>
>
>     James Gould
>     Distinguished Engineer
>     [email-masked]
>
>     703-948-3271
>     12061 Bluemont Way
>     Reston, VA 20190
>
>     On 6/11/18, 9:55 AM, "regext on behalf of Gavin Brown" <regext-
> [email-masked] on behalf of [email-masked]> wrote:
>
>         +1.
>

---

From: "Gould, James" <[email-masked]>
Date: Mon, 11 Jun 2018 19:57:35 +0000

Patrick,

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 <loginSec:pw> and <loginSec:newPw> 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 <pw> and <newPw> 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).

JG - I too have not seen an extension of the authorization mechanism in EPP yet with the use of <domain:authInfo><domain:ext>…</domain:ext></domain:authInfo>.

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

    --

      Patrick Mevzek

    regext mailing list

    [email-masked]

---

From: Marc Groeneweg <[email-masked]>
Date: Wed, 13 Jun 2018 07:52:13 +0000

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" <[email-masked] on behalf of shollenbeck=[email-masked]> wrote:

    Works for me, Jim.
    
    Scott

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 14 Jun 2018 00:45:12 +0200

On Mon, Jun 11, 2018, at 19:43, Gould, James wrote:
> 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 
> policies can be found in <blah blah> [reference here]".  Scott's 
> language can be added to the Security Considerations section of the 
> draft.
> 

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

---

From: Patrick Mevzek <[email-masked]>
Date: Thu, 14 Jun 2018 00:48:02 +0200

On Mon, Jun 11, 2018, at 21:57, Gould, James wrote:
>     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

---

From: Pieter Vandepitte <[email-masked]>
Date: Thu, 14 Jun 2018 06:40:16 +0000

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 <http://www.dnsbelgium.be>

On 14/06/18 00:45, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    -- 
      Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Thu, 14 Jun 2018 12:42:25 +0000

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

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

On 6/13/18, 6:45 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    
    
    -- 
      Patrick Mevzek

---

From: "Gould, James" <[email-masked]>
Date: Thu, 14 Jun 2018 13:12:41 +0000

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

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 6/13/18, 6:48 PM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    --

      Patrick Mevzek

    regext mailing list

    [email-masked]