Subject: [regext] Minor comment on draft-gould-regext-login-security-02

From: "Patrick Mevzek" <[email-masked]>
Date: Fri, 11 Jan 2019 02:11:49 -0500

Dear James and Matthew,

A minor point while implementing it (finished, will announce it soon).

If a new "long" password is presented, it is exchanged in the <newPW>
node.

However for events, among the list of possible values for type you have: newPw

I see no reason for the different casing.

I recommend that the type value is also newPW or, to be more in line with other
values to just spell it out in full, hence "newPassword".

In fact I have found out one instance of
<loginSec:newPw>
for the XML node, so maybe a leftover of a previous change.
You may want to double check all examples/quotes of the node name to have the proper casing.

Also since all 3 nodes are optional under loginSec you may wish to specify that the extension should be sent only if at least one of the node is present beneath it.
Or what the server should reply if it gets only an empty root node.
(and on a more philosophical level, I feel userAgent should not be defined in this extension because it has nothing to do with passwords and could be useful just be itself; it is useless however to create an extension just for it so I can understand why putting it there, but it is still bundling things together that are not related)

And maybe provide some advice about downgrade, what about the following chain of events:
- change of password using loginsec:newPW for a long password
- but then change back to short password using pure newPW without the loginSec part.

Allowed? Recommended?

-- 
  Patrick Mevzek
  [email-masked]

---

From: "Gould, James" <[email-masked]>
Date: Fri, 11 Jan 2019 18:21:19 +0000

Patrick,

Thank you for implementing draft-gould-regext-login-security and the feedback.  I provide responses to your feedback below prefixed with "JG - ".      
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

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

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

    Dear James and Matthew,

    

    
 
JG - Thank you for finding the inconsistency to the case of the <loginSec:newPW> element in the extension.  The goal is to match the case of the <newPW> element in RFC 5730, so I'll be sure to consistently reference "newPW" throughout in the next version of the draft.  

JG - I agree some text would be helpful here.  I would anticipate that even if there was an empty <loginSec:loginSec> element, the server would only process the elements passed, so the server would do nothing with the empty element.  I'll take a shot with some text in the next version of the draft.

JG - The Login Security Extension goes beyond passwords and relates to security in general.  The userAgent helps identify current and future security events that can be included in the login response.  

    Allowed? Recommended?
 
JG - Yes, it would be allowed by the extension, but may not be allowed by server policy.  The <loginSec:newPW> element is only required if the new password is longer than the RFC 5730 maximum of 16 characters.  The same holds true for the <loginSec:pw> element.  I recommend that the client increase instead of decrease the strength of the passwords, but there is nothing in the extension that would disallow it.       

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

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Fri, 11 Jan 2019 18:52:49 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Gould, James
> Sent: Friday, January 11, 2019 1:21 PM
> To: [email-masked]; [email-masked]
> Subject: [EXTERNAL] Re: [regext] Minor comment on draft-gould-regext-
> login-security-02
>
> Patrick,
>
> Thank you for implementing draft-gould-regext-login-security and the
> feedback.  I provide responses to your feedback below prefixed with "JG - ".
>
> —
>
> JG
>
>
>
> James Gould
> Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> On 1/11/19, 2:12 AM, "regext on behalf of Patrick Mevzek" <regext-
> [email-masked] on behalf of [email-masked]> wrote:
>
>     Dear James and Matthew,
>
> JG - Thank you for finding the inconsistency to the case of the
> <loginSec:newPW> element in the extension.  The goal is to match the case
> of the <newPW> element in RFC 5730, so I'll be sure to consistently
> reference "newPW" throughout in the next version of the draft.
>
>     Also since all 3 nodes are optional under loginSec you may wish to specify
> that the extension should be sent only if at least one of the node is present
> beneath it.
> JG - I agree some text would be helpful here.  I would anticipate that even if
> there was an empty <loginSec:loginSec> element, the server would only
> process the elements passed, so the server would do nothing with the
> empty element.  I'll take a shot with some text in the next version of the
> draft.
>
>     (and on a more philosophical level, I feel userAgent should not be defined
> in this extension because it has nothing to do with passwords and could be
> useful just be itself; it is useless however to create an extension just for it so
> I can understand why putting it there, but it is still bundling things together
> that are not related)
>
> JG - The Login Security Extension goes beyond passwords and relates to
> security in general.  The userAgent helps identify current and future security
> events that can be included in the login response.
>
> JG - Yes, it would be allowed by the extension, but may not be allowed by
> server policy.  The <loginSec:newPW> element is only required if the new
> password is longer than the RFC 5730 maximum of 16 characters.  The same
> holds true for the <loginSec:pw> element.  I recommend that the client
> increase instead of decrease the strength of the passwords, but there is
> nothing in the extension that would disallow it.

Jim, that sounds like it's worth addressing in the Security Considerations section of the document.

Scott

---

From: "Gould, James" <[email-masked]>
Date: Fri, 11 Jan 2019 19:02:17 +0000

Scott,

I'll take a shot at adding some text to the Security Considerations section for this.  
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

---

From: "Gould, James" <[email-masked]>
Date: Tue, 15 Jan 2019 19:07:06 +0000

Patrick,

I addressed your feedback in draft-gould-regext-login-security-03, which did require bumping the XML schema version up to urn:ietf:params:xml:ns:epp:loginSec-0.3.  I also made the corresponding change for the newPW case issue to draft-gould-regext-login-security-policy-02.  Please review and let me know if you identify any other items.  

Thanks,
  
—
 
JG

James Gould
Distinguished Engineer
[email-masked]

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

On 1/11/19, 1:21 PM, "regext on behalf of Gould, James" <[email-masked] on behalf of jgould=[email-masked]> wrote:

    Patrick,

    —
     
    JG

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

    
        Dear James and Matthew,

        

        

    

        
        
        Allowed? Recommended?

        -- 
          Patrick Mevzek
          [email-masked]