[regext] review of draft-ietf-regext-login-security-03

[Martin Casanova <[e-mail]>]

Jim

Since we support that draft I started implementing and read it again 
more carefully. I have the following comments / feedback

1. (comment) Event type "cipher" or "tlsProtocol" :

In case the client uses deprecated protocol or cipher we currently hang 
up the TLS connection immediately so there is no possibility to send a 
type "error" security event.
At chapter 3.1 near "exDate" is written that "At expiry there MAY be an 
error to connect or MAY be an error to login." So in case of an error to 
connect you run in the same situation and will not be able to send back 
a "error" level event but thats OK. However it is useful to warn the 
client during a transition period when we know that we are going to 
disable a certain cipher or TLS protocol on a specific day in the future.


2 . (comment) Event type "newPw":
Here we currently use  2306 "Parameter value policy error" and write in 
the <reason> of <extValue> element that the new password was too weak.
I guess we would use the loginSec Event in the future in case the 
extension was specified at login whether the pw was changed via 
login-security extension or not.

I know that you have foreseen draft-gould-regext-login-security-policy 
to query about password complexity but I think for convenience of the 
registrar it would still be nice to somehow include the password 
requirement in the response even if it is redundant. Otherwise one has 
to implement draft-gould-regext-login-security-policy  at the same time 
or communicate the requirement out of band.

maybe like that

    S:        <loginSec:event
    S:          type="newPW"
    S:          value="expression: (?=.*\d)(?=.*[a-zA-Z])(?=.*[\x21-\x2F\x3A-\x40\x5B-\x60\x7B-\x7E]) (?!^\s+) (?!.*\s+$)(?!.*\s{2,})^[\x20-\x7e]{16,128}$"
    S:          level="error">
    S:          New password does not meet complexity requirements
    S:        </loginSec:event>
Page 10:

    S:    <result code="2200">
    S:      <msg>Authentication error</msg>


Are you sure you want to return a 2200 and not a 2306 Parameter value 
policy error in this case (page 10). I don't see a reason why this 
should be another return code with or without extension.


3. (question) Event type "stat" :

How often would you send back this event

    <loginSec:event
      type="stat"
      name="failedLogins"
      level="warning"
      value="100"
      duration="P1D">
      Excessive invalid daily logins
    </loginSec:event>

Only once with first successful login after the series of failed ones or 
for a whole day ? I suggest one time with first successful login.


4. (question) In chapter 4.1 EPP <login> Command is written

..

internal contiguous
        whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage
        return), and #x20 (space) is replaced with a single #x20 (space).
..

Since this is "normal" XML parsing behavior should there not be 
reference to where this is described for general XML processing. (I 
don't know where that would be though)


5.  (suggestion) The element  <loginSec:userAgent> could be more 
structured to make it easier for the registry to parse the different 
fields and to give a hint to the registrar what information should be 
provided.

Therefore I suggest  child elements for example

<os>           Operating System
<client>      Client technology (eg. java)
<version> Client software version (eg. 1.8.0) etc.

Thanks


Martin Casanova


-- 
---
SWITCH
Martin Casanova, Domain Applications
Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland
phone [phone], direct [phone]
[e-mail],www.switch.ch  
  
Working for a better digital world