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

From: "Gould, James" <[email-masked]>
Date: Tue, 29 Oct 2019 19:15:39 +0000

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

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

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

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

From: regext <[email-masked]> on behalf of Barry Leiba <[email-masked]>
Date: Tuesday, October 29, 2019 at 12:10 AM
To: "[email-masked]" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>
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 <[email-masked]<mailto:[email-masked]>> 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/

---

From: Barry Leiba <[email-masked]>
Date: Tue, 29 Oct 2019 15:20:21 -0400

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 <[email-masked]> 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
>
>
>
>
> *James Gould *Distinguished Engineer
> [email-masked]
>
> 703-948-3271
> 12061 Bluemont Way
> Reston, VA 20190
>
> Verisign.com <http://verisigninc.com/>
>
>
>
> *From: *regext <[email-masked]> on behalf of Barry Leiba <
> [email-masked]>
> *Date: *Tuesday, October 29, 2019 at 12:10 AM
> *To: *"[email-masked]" <
> [email-masked]>
> *Cc: *"[email-masked]" <[email-masked]>
> *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 —
>
> 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 – This will be fixed.  There are two occurrences of “free form” that
> will be changed to “free-form” in section 3.1.
>
>
>
> 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.
>
>
>
> 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.
>
>
>
> 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: >>
>
> 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 —
>
>
>
>    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 <
> [email-masked]> 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/
>
>