Re: [regext] AD review for draft-ietf-regext-login-security-04

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

Barry,

Thank you for the review and feedback.  I provide my responses to your feedback inline below.  I will post draft-ietf-regext-login-security-05 with the changes based on your feedback.

--

JG

[cid:[e-mail]933A30]

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

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

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

From: regext <[e-mail]> on behalf of Barry Leiba <[e-mail]>
Date: Tuesday, October 29, 2019 at 12:10 AM
To: "[e-mail]" <[e-mail]>
Cc: "[e-mail]" <[e-mail]>
Subject: [regext] AD review for draft-ietf-regext-login-security-04

I have mostly editorial comments that I hope you’ll consider, but that will not block anything.  My comment below for Section 4.1 is, though, something I want to discuss before I start last call.


— Section 1.1 —
Please use the new BCP 14 boilerplate and references; see RFC 8174

JG – That will be fixed.


   In examples, "C:" represents lines sent by a protocol client and "S:"
   represents lines returned by a protocol server.  Indentation and
   white space in examples are provided only to illustrate element
   relationships and are not a REQUIRED feature of this protocol.

This is not a BCP 14 key word, and should be “required” in lower case.

JG – That will be changed.

— Section 2 —
For other similar regext documents, ADs have suggested that the compatibility/migration recommendations be left in the document for publication, rather than asking the RFC Editor to remove them.  Unless there’s a good reason not to publish this section, please remove the request to the RFC Editor.

JG – I will remove the note to the RFC Editor so that the section remains.

— Section 3.1 —

   There MAY be multiple
   events returned that provides information for the client to address.

“provide”


JG – This will be fixed.

   The <loginSec:event> MAY include a free form description.

There should be a hyphen in “free-form” here and elsewhere when it’s used as a modifier.

JG – This will be fixed.  There are two occurrences of “free form” that will be changed to “free-form” in section 3.1.

   The enumerated list of "type" values include:

“includes”

JG – “include:” will be changed to “includes:”.

       "password":  Identifies a password expiry event, where the
           password expires in the future or has expired based on the
           "exDate" date and time.
       "certificate":  Identifies a client certificate expiry event,
           where the client certificate will expire at the "exDate" date
           and time..

Why are these worded differently?  Is there a reason they do not both say, << where the [thing] has expired or will expire at the “exDate” date and time. >> ?

JG – The wording is different, since if the certificate expires, the connection will fail prior to getting to the login command.  If the password expires, the client can execute the login command and therefore the server can include the security event post the expiry of the password in the login response.  Therefore the server can only warn the client of an expired certificate in the login response prior to its expiry, but the server can inform the client of an expired password in the login response prior to or after the expiry of the password.

   "lang":  Identifies the language of the free form description if the
       negotiated language is something other than the default value of
       "en" (English).

This seems to imply that it should never be set to “en”.  If that isn’t what’s meant, it might be better said as, << Identifies the language of the free-form description.  The default is “en” (English). >>.

JG – This language was borrowed from the various EPP RFCs include RFC 5731.  There is no intent to disallow inclusion of the “lang” attribute if the value is “en”.  I’ll change it based on your proposed language to make it clearer, but with “negotiated language” instead of “language”, since the greeting and the login command negotiate the language to use.

   Example login security event for a password expiring in a week:

There’s no context for “in a week.”  How about this?: << Example login security event for password expiration, where the current date is 2018-03-26: >>
(And similarly for the related example in Section 4.1.)

JG – Yes, that will cover future dates, I’ll make the change.  I believe the correct current date is 2018-03-25 for an expiry on 2018-04-01 in a week.  I’ll make a similar change for the example in section 4.1.

— Section 4.1 —

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

Two things here:


  1.  Are there any limitations on valid characters other than the four mentioned?  Is there any server policy involved?

JG – There are no additional constraints for valid characters in the draft or in RFC 5730.  The constraints defined in the draft are based on the selection of the XML schema “token” type, which matches the type in RFC 5730.  The XML schema “token” type constraints are explicitly defined in the draft based on feedback from the Working Group.  Server policy will define the specific password constraints (e.g., characters, minimum length, maximum length, restricted words) for the server.  An example is the use of draft-gould-regext-login-security-policy to define the password rules in EPP.

2. What is the reason for collapsing those, four characters, and not allowing a password to actually contain, say, a tab, or three consecutive spaces?  What about all the other Unicode characters that represent spaces in various forms, or zero-length characters?

JG – One goal of the draft is remove the 16 character maximum constraint in RFC 5730 while supporting the same XML schema type of “token”.  The trimming and collapsing of whitespace is a feature of the XML schema “token” type that exists today based on what’s defined in RFC 5730.

—
Barry


On Fri, Oct 25, 2019 at 9:44 AM James Galvin via Datatracker <[e-mail]<mailto:[e-mail]>> wrote:
James Galvin has requested publication of draft-ietf-regext-login-security-04 as Proposed Standard on behalf of the REGEXT working group.

Please verify the document's state at https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/