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

["Alexey Melnikov" <[e-mail]>]

Hi James,

On Thu, Jan 23, 2020, at 9:29 PM, Gould, James wrote:
> Alexey,

 [snip]

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

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