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

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

Patrick, 

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



James Gould
Distinguished Engineer
[e-mail]

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

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

On 6/5/18, 1:32 AM, "regext on behalf of Patrick Mevzek" <[e-mail] on behalf of [e-mail]> 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 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?
  
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.  

  
    - 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
    [e-mail]
    https://www.ietf.org/mailman/listinfo/regext