Subject: [regext] Alexey Melnikov's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)

From: Alexey Melnikov via Datatracker <[email-masked]>
Date: Thu, 23 Jan 2020 02:58:55 -0800

Alexey Melnikov has entered the following ballot position for
draft-ietf-regext-login-security-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

Thank you for this document. I have several small comments similar to what was
raised by Roman and Ben:

1) In 4.1:

   <loginSec:userAgent>:  OPTIONAL client user agent that identifies the
       client application software, technology, and operating system
       used by the server to identify functional or security
       constraints, current security issues, and potential future
       functional or security issues for the client.  The
       <loginSec:userAgent> element MUST contain at least one of the
       following child elements:

       <loginSec:app>:  OPTIONAL name of the client application software
           with version if available, such as the name of the client SDK
           "EPP SDK 1.0.0".
       <loginSec:tech>:  OPTIONAL technology used for the client
           software with version if available, such as "Java 11.0.2".
       <loginSec:os>:  OPTIONAL client operating system used with
           version if available, such as "x86_64 Mac OS X 10.11.6".

Is there a registry of allowed values or at least some instructions how to
construct these values? There are probably several existing IETF registries
that can be reused.

If these values are not supposed to be used by servers for anything other than
logging (i.e. if they can't be used to work around bugs), then the document
needs to say that.

2) In the same section:

   <loginSec:pw>:  OPTIONAL plain text password that is case sensitive,
       has a minimum length of 6 characters, and has a maximum length
       that is up to server policy.  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 element
       MUST only be used if the [RFC5730] <pw> element is set to the
       "[LOGIN-SECURITY]" value.

What is the definition of "whitespace"? Does this only include characters
listed above or does it also include other Unicode characters (e.g. Unicode
whitespace property)? If the former, then instead of using "whitespace that
includes ..." use something like "whitespace is defined as one of ..."

   <loginSec:newPW>:  OPTIONAL plain text new password that is case
       sensitive, has a minimum length of 6 characters, and has a
       maximum length that is up to server policy.  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 element MUST only be used if the [RFC5730] <newPW> element
       is set to the "[LOGIN-SECURITY]" value.

As above.

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

8.  Security Considerations

   The extension leaves the password (<pw> element) and new password
   (<newPW> element) minimum length beyond 6 characters and the maximum
   length up to sever policy.

Typo: sever -> server

---

From: "Gould, James" <[email-masked]>
Date: Thu, 23 Jan 2020 21:29:51 +0000

Alexey,

Thank you for your review and feedback.  My responses are embedded below.

-- 
 
JG

James Gould
Distinguished Engineer
[email-masked] <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/[email-masked]>

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

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

On 1/23/20, 5:59 AM, "Alexey Melnikov via Datatracker" <[email-masked]> wrote:

    

    1) In 4.1:

    

JG - I'm not aware of any registries that exist that describes how to construct these values.  I believe to address Roman's, Ben's and your feedback, I will provide an example of how to construct these values.

JG - The servers can leverage this information for more than logging; although logging is the most common use case.  The most useful element for identification is the <loginSec:app>, where if there is a known client application such as an EPP SDK, the server can key off of the EPP SDK version to proactively identify potential security issues to report back to the client.  The server may already know the client application patterns or can identify the client application patterns using the logs to create rules for specific clients applications.  The additional <loginSec:tech> and <loginSec:os>  elements are useful to identify future security policy issues, such as deprecating or removing TLS cipher suites or TLS protocols.  The short answer to your question is that the server can utilize the elements for logging and for driving security event rules, but this is beyond the scope of the extension specification.       
    
    2) In the same section:

   
JG - The definition of "whitespace" is based on the definition for XML schema whiteSpace (https://www.w3.org/TR/xmlschema11-2/#rf-whiteSpace), which does not include non-ASCII whitespace.  Validating XML parsers will apply the XML schema whitespace rules defined for the XML Schema "token" type (https://www.w3.org/TR/xmlschema11-2/#token), which is explicitly included in the description of the <loginSec:pw> element based on feedback from the working group.  I don't recommend use of non-ASCII characters for passwords, but I don't believe the extension should disallow it.  

    As above.
    
JG - Same answer as for the <loginSec:pw> element above.

    
    
    Typo: sever -> server
    
JG - I found this as well upon further review, so it will be addressed.

---

From: Alexey Melnikov <[email-masked]>
Date: Fri, 24 Jan 2020 09:10:09 +0000

Hi James,
Just replying to 1 point below:

> On 23 Jan 2020, at 21:29, Gould, James <[email-masked]> wrote:
> 
>    2) In the same section:
> 

Please clarify this in the document. Probably the easiest way is to add definition of whitespace to the terminology section.

BTW, I believe Precis framework will canonicalize all Unicode whitespaces (around 33 different characters) to ASCII space.

Best Regards,
Alexey

---

From: "Gould, James" <[email-masked]>
Date: Fri, 24 Jan 2020 21:24:53 +0000

Alexey,

I'll go ahead and add the following description of "whitespace" in section 1.1 "Conventions Used in This Document":

"whitespace" is based on the definition for the XML schema whiteSpace datatype in [W3C.REC-xmlschema-2-20041028], which only includes the ASCII whitespace characters #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20 (space).  

-- 
 
JG

James Gould
Distinguished Engineer

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

On 1/24/20, 4:10 AM, "Alexey Melnikov" <[email-masked]> wrote:

    Hi James,

    

    Best Regards,
    Alexey

---

From: "Hollenbeck, Scott" <[email-masked]>
Date: Mon, 27 Jan 2020 12:39:16 +0000

> -----Original Message-----
> From: regext <[email-masked]> On Behalf Of Gould, James
> Sent: Friday, January 24, 2020 4:25 PM
> To: Alexey Melnikov <[email-masked]>
> Cc: [email-masked]; Joseph Yee <[email-masked]>;
> The IESG <[email-masked]>; [email-masked]; [email-masked]
> Subject: [EXTERNAL] Re: [regext] Alexey Melnikov's Discuss on draft-ietf-
> regext-login-security-07: (with DISCUSS and COMMENT)
> 
> Alexey,
> 
> "whitespace" is based on the definition for the XML schema whiteSpace
> datatype in [W3C.REC-xmlschema-2-20041028], which only includes the ASCII
> whitespace characters #x9 (tab), #xA (linefeed), #xD (carriage return), and
> #x20 (space).

I'd recommend stronger language. It's not just "based on" the definition for the XML schema whiteSpace datatype, that datatype is normatively incorporated by reference. Perhaps something like this:

'"whitespace" is defined by the XML schema whiteSpace datatype in [W3C.REC-xmlschema-2-20041028], which only includes the ASCII whitespace characters #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20 (space).'

Scott

---

From: "Gould, James" <[email-masked]>
Date: Mon, 27 Jan 2020 13:05:00 +0000

Scott,

Thanks, that is better.

-- 
 
JG

James Gould
Distinguished Engineer

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

    

    Scott

---

From: "Alexey Melnikov" <[email-masked]>
Date: Mon, 27 Jan 2020 14:02:25 +0000

Hi James,

> Alexey,

 [snip]

> JG - I'm not aware of any registries that exist that describes how to 
> construct these values.  I believe to address Roman's, Ben's and your 
> feedback, I will provide an example of how to construct these values.

I am not insisting that you should use these, but some examples:

https://www.iana.org/assignments/operating-system-names/operating-system-names.xhtml#operating-system-names-1

and probably more interesting:

https://www.iana.org/assignments/iodef2/iodef2.xhtml#softwarereference-dtype

The latter points to NIST's Common Platform Enumeration and ISO 19770 software identification (SWID).

> JG - The servers can leverage this information for more than logging; 
> although logging is the most common use case.  The most useful element 
> for identification is the <loginSec:app>, where if there is a known 
> client application such as an EPP SDK, the server can key off of the 
> EPP SDK version to proactively identify potential security issues to 
> report back to the client.  The server may already know the client 
> application patterns or can identify the client application patterns 
> using the logs to create rules for specific clients applications.  The 
> additional <loginSec:tech> and <loginSec:os>  elements are useful to 
> identify future security policy issues, such as deprecating or removing 
> TLS cipher suites or TLS protocols.  The short answer to your question 
> is that the server can utilize the elements for logging and for driving 
> security event rules, but this is beyond the scope of the extension 
> specification.       

I think saying something along these lines would be helpful.

Best Regards,
Alexey

---

From: "Alexey Melnikov" <[email-masked]>
Date: Tue, 28 Jan 2020 15:21:31 +0000

Hi James,

(Top post)

Your changes look good to me.

Best Regards,
Alexey

> My responses are embedded below.

>  On 1/27/20, 9:02 AM, "Alexey Melnikov" <[email-masked]> wrote:

>  > Thank you for this document. I have several small comments similar

>  > to what was

> JG - I believe inclusion of the example ABNF for constructing the <loginSec:userAgent> child element values will provide the needed clarification. It looks like you feel the same way based on your response to Roman's thread. I'll address the usage of the information.

>  > If these values are not supposed to be used by servers for anything

>  > other than

>  > logging (i.e. if they can't be used to work around bugs), then the

>  > document

> JG - To address this, I can update the description of the <loginSec:userAgent> as:

> OPTIONAL client user agent information that identifies the client application software, technology, and operating system used by the server to identify functional or security constraints, current security issues, and potential future functional or security issues for the client. *The server may use the information for real-time identification and client notification of security issues, such as keying off of the client application software for executing security rule checks. The server may capture the information to identify future security policy issues, such as deprecating or removing TLS cipher suites or TLS protocols.* The <loginSec:userAgent> element MUST contain at least one of the following child elements: