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

["Gould, James" <[e-mail]>]

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
[e-mail]

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

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

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

    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
    [e-mail]
    
    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" <[e-mail] on behalf of [e-mail]> wrote:
    
        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.
     
    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.
        Or what the server should reply if it gets only an empty root node.
    
    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.  
        
        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?
     
    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
          [e-mail]
        
        _______________________________________________
        regext mailing list
        [e-mail]
        https://www.ietf.org/mailman/listinfo/regext
        
    
    _______________________________________________
    regext mailing list
    [e-mail]
    https://www.ietf.org/mailman/listinfo/regext