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 +41 44 268 15 55, direct +41 44 268 16 25
[email protected],www.switch.ch
Working for a better digital world
_______________________________________________
regext mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/regext
