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

[Barry Leiba <[e-mail]>]

Jim, thanks for accepting most of my edits and for addressing my question
about the password characters.  It just seems odd to me that you can't use
<< my#x20#x20#x20pw >> as a password, but you can use, say, <<
my#x20#xA0#x20pw >> (or any of a number of other variations with other
Unicode space characters.  But the reason sounds... reasonable, so: post a
rev and I'll last-call it.

b


On Tue, Oct 29, 2019 at 3:15 PM Gould, James <[e-mail]> wrote:

> 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
>
>
> [image: cid:[e-mail]933A30]
>
>
> *James Gould *Distinguished Engineer
> [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]> 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/
>
>