Subject: [regext] Benjamin Kaduk's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)

From: Benjamin Kaduk via Datatracker <[email-masked]>
Date: Wed, 22 Jan 2020 18:30:25 -0800

Benjamin Kaduk has entered the following ballot position for
draft-ietf-regext-login-security-07: Discuss

When responding, please keep the subject line intact and reply to all
email addresses included in the To and CC lines. (Feel free to cut this
introductory paragraph, however.)

Please refer to https://www.ietf.org/iesg/statement/discuss-criteria.html
for more information about IESG DISCUSS and COMMENT positions.

The document, along with other ballot positions, can be found here:
https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/

----------------------------------------------------------------------
DISCUSS:
----------------------------------------------------------------------

This document+extension claims to provide "Login Security" but has no
substantive discussion of why the previous mechanism was insecure and
how this extension improves the security.  I find it hard to believe
that any such discussion could fail to acknowledge that sending the
plaintext password (after only processing for whitespace) to the server
(akin to SASL PLAIN) is severely lacking on several security-related
fronts.  While it may be possible that there is adequate justification
for only pursuing the smallest incremental improvement in the current
document, it would require some additional discussion to convince me
that the "small incremental improvement" of removing a protocol-level
maximum password length is the best choice at this time, as opposed to a
broader approach that attempts to tackle more axes upon which "security"
can be measured.  Does this discussion already exist somewhere?
(This document also includes functionality for relatively rich event
notifications, that are likely worth doing in their own right, but do
not seem to be "security improvements" per se, to me.)

I also think that there many places in the description of the XML
elements/attributes that are underspecified, given that XML is
traditionally thought of as a machine-readable format.  Several
instances have already been noted by my fellow IESG members (e.g.,
custom events, statistical warnings, "value" attribute), but they seem
prevalent enough that I would like to see the authors make a pass
through all the protocol elements and assess which ones need to be
machine-readable vs. only for human consumption, and accurately document
that.  I list some examples in the Comment section, and specifically
call out the <loginSec:pw> and <loginSec:newPW> encodings, which leaves
many ambiguities with respect to what non-ASCII behavior is allowed
other than OpaqueString, what constitutes "whitespace" in the two listed
situations, and whether the password encoding is related to the XML
document encoding of the request.  As I note in the comment, my
understanding was that the PRECIS profiles were intended to be used at a
protocol-level (vs. a deployment level) and thus the nature of the
profile usage would be fairly tightly specified by this document;
perhaps the responsible AD (or someone else) will correct my
understanding.

I'd also like to have a bit of discussion regarding the prohibition of
using the literal string "[LOGIN-SECURITY]" as an actual password.
Section 3.2 notes '''[t]he server MUST NOT allow the client to set the
password to the value "[LOGIN-SECURITY]"''', and though I did not do a
full case-by-case analysis, this feels like something that a server
implementing this extension wants to do always, regardless of whether a
given client indicates support for this extension.  That seems like it
could meet the criteria to mark this document as Updating RFC 5730, to
reserve this sentinel value.  Is there more reasoning for or against
having this document Update the password-handling behavior RFC 5730 to
reserve this sentinel value?

----------------------------------------------------------------------
COMMENT:
----------------------------------------------------------------------

(per the first Discuss point) I understand that per RFC 5734 we're
always using TLS client certificates to identify the client machine (but
can have multiple user credentials using the same client certificate for
their TLS connections), but that doesn't completely alleviate the
problems inherent to passwords (see Discuss).  For example, with
passwords there's the risk of password theft, whether from the on-disk
server password database or by leveraging a fraudulent TLS server
certificate to capture live incoming traffic, but that's not a complete
listing.

Section 1

(Side note: I note that the phrase "security event" is used as a term of
art by the SECEVENT WG, for the "security event token" work of RFC 8417
and its consumers.  They seem to have a somewhat different set of
expected "security events", not that this document necessarily needs to
change in response.)

(side note: IMHO, the long list of security-event attributes (and
possibly the security events themselves) is not needed in a high-level
Introduction like this.  But that's not an actionable comment.)

Section 2

   Servers which implement this extension SHOULD provide a way for
   clients to progressively update their implementations when a new
   version of the extension is deployed.

   Servers SHOULD (for a temporary migration period up to server policy)
   provide support for older versions of the extension in parallel to
   the newest version, and allow clients to select their preferred
   version via the <svcExtension> element of the <login> command.

I see the opsdir review (and response), but I can't help wondering if
this second paragraph is a proposed way to meet the
requirement^Wrecommendation of the first paragraph.  If so, it would be
tempting to make the first one into a "MUST", since we really think it's
important that servers should do this in some way, though we don't have
as strong an opinion on how.  (I do not expect my
reasoning to convince you more if the opsdir review did not, though, so
feel free to treat this as a side note.)

I also think that the response to the genart review was incomplete --
the genart reviewer's point about knowing, given two versions of this
extension, which one is said to be "newer" is perhaps still open.
(Suppose version 1.1 is published in 2021, 2.0 in 2022, and 1.2 in 2.23.
Is version 2.0 "newer than" 1.2?)  I didn't find much in 5730 that we
could lean on, though it's kind of drowned out by the sea of '''<?xml
version="1.0"'''...

Section 3.1

   The <loginSec:event> MAY include a free-form description.  All of the

nit: I'm not sure whether we want to consider "<loginSec:event>" as an
adjective ("<loginSec:event> element") or a noun in its own right, but I
am having a hard time with the definite article in the current text.
Since the previous sentence talks about multiple events being allowed,
maybe "Each" is best?  (Also, is this description "as the body of the
element"?)

   "type":  A REQUIRED attribute that defines the type of security
       event.  The enumerated list of "type" values includes:
       [...]

(side note: the specific "type" values chosen by the authors is rather
different from what I would have written.  It feels a bit presumptuous
to assume that expiration is the only password- or certificate-related
event that could occur and privilege those events to have the bare
"password" and "certificate" type values, for example.  I don't know
what the server would do to convey knowledge of a breach of the server's
password database file, for example  But what's there is clearly
documented so I have no real grounds to object to it per se.)

   "exDate":  Contains the date and time that a "warning" level has or
       will become an "error" level.  At expiry there MAY be an error to
       connect or MAY be an error to login.  An example is an expired

The "MAY"s feel a little out of place here, and I would suggest "At this
expiration time, the error might be realized as either a connection
failure or a login failure" to also avoid the "error to" construction
that flows strangely to my eye.

   "value":  Identifies the value that resulted in the login security
       event.  An example is the negotiated insecure cipher suite or the
       negotiated insecure TLS protocol.

Right now the encoding used for this value feels highly under-specified.
Consider the case of an insecure TLS cipher suite.  IANA manages a table
of TLS ciphersuites
(https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4)
so one might see a pair of hex values, a single four-hex-digit-string, a
human-readable "Description", the decimal value corresponding to the
four-hex-digit-string, etc.  I mostly expect that this value will only
ever be displayed to a human and is not expected to be
machine-parseable, but we really need to say that if so (and perhaps
also that the human-readable string form is preferred when there are
multiple choices).

   Example login security event for password expiration, where the
   current date is 2018-03-25:

I appreciate the use of a "current date" for purposes of the example;
that's a nice touch!

Section 3.2

   The <loginSec:pw> element MUST override the [RFC5730] <pw> element
   only if the <pw> contains the predefined value of "[LOGIN-SECURITY]",
   which is a constant value for the server to use the <loginSec:pw>
   element for the password.  Similarly, the <loginSec:newPW> element

nits(?): the "MUST override [...] only if" construction seems prone to
misreading (both here and for <newPW>").  Is it a prohibition against
overriding in other scenarios?  A mandate to override?  Both?  Perhaps a
declarative "When the <pw> element contains the predefined value
"[LOGIN-SECURITY]", the <loginSec:pw> element overrides the <pw>
element" is more clear.  Also, there seems to be a word or two missing
for the current formulation to parse properly, in "is a constant value
for the server to use the <loginSec:pw> element for the password" --
perhaps saying that this "indicates to" the server.  (I myself would use
the phrase "sentinel value" to describe this password string, but maybe
that's overused.)

Section 3.3

   Coordinated Time (UTC) using the Gregorian calendar.  The extended
   date-time form using upper case "T" and "Z" characters defined in
   [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time
   values, as XML Schema does not support truncated date-time forms or
   lower case "T" and "Z" characters.

nit(?): "the EPP XML Schema" or "this protocol's XML Schema", I think.

Section 4.1

Sending detailed userAgent information seems to merit some discussion of
privacy considerations w.r.t user profiling and/or tracking.

   <loginSec:userAgent>:  OPTIONAL client user agent that identifies the
       client application software, technology, and operating system

nit: is this better as "client user agent information"?

   <loginSec:pw>:  OPTIONAL plain text password that is case sensitive,
       has a minimum length of 6 characters, and has a maximum length

Why is it optional?
Also, 6 characters feels a bit short for a password, these days.  (Yes,
I did pull up SP 800-63B.)

       that is up to server policy.  All leading and trailing whitespace
       is removed, and all internal contiguous whitespace that includes

We list explicitly the values considered "internal whitespace" but not
"leading and trailing whitespace".  I note that using Unicode attributes
to determine whitespace nature (which would seem reasonable to many
people) will recognize quite a few more codepoints as being whitespace,
and it is important to have a clear and unambiguous procedure.

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

What does "only be used" mean?  Is this restricting transmission from
the client or processing by the server, or both?  What should the error
handling behavior be when it is present and it's not supposed to be?

[ditto for <loginSec:newPW>]

   (space) - #x7E (~), with high entropy, such as 128 bits.  If non-
   ASCII characters are supported with the plain text password, then use
   a standard for passwords with international characters, such as the
   OpaqueString PRECIS profile in [RFC8265].

My understanding is that the PRECIS profiles are intended to be used at
a per-protocol level, not a per-deployment level.  So this needs to be
stronger than just "such as".

Also, if (as per the example) this is carried in a client's XML request
that contains an "encoding" attribute, what's the interaction between
that encoding and any per-password encoding for non-ASCII data?

[I think I asked about repeating the "ABC-12345" clTRID for multiple
examples in the same document for a previous EPP document, but forget
why it was deemed to be okay.  Assuming that I do remember the tenor of
the prevous discussion correctly, no response is needed here.]

   C:          <loginSec:os>x86_64 Mac OS X 10.11.6</loginSec:os>

(macOS 10.11 feels a bit dated for 2010)

   C:        <loginSec:pw>this is a long password</loginSec:pw>

(side note: Long, but fairly low-entropy.  "Correct horse battery
staple" might get a smile from some readers...  Similarly for the other
examples)

   Upon a completed login command (success or failed), the extension
   MUST be included in the response based on both of the following
   conditions:

I suggest "MUST be included in the response when both of the following
conditions hold".

   Example EPP response to a failed login command where the password has
   expired and the new password does not meet the server complexity
   requirements:

nit: the exDate given here is 2018-03-26, but the most recent "time of
request" we listed was 2018-03-25, which is before this nominal
expiration date.  It would be nice to either mention a new "time of
request" or mak the examples more consistent across each other.

I also wonder about the usefulness of sending detailed errors back to an
unauthenticated user.  It would, for example, probably not be a good
idea to report various statistical events to an unauthenticated user
that's potentially an attacker seeking information for further attacks.

Section 8

I think it would be appropriate to have a brief note that while this
extension increases the maximum length of password that may be used for
EPP authentication, it still involves sending unmodified passwords to
the server for verification, and as such retains the security
considerations of doing so from RFC 5730.

The maximum <loginSec:pw> length that Section 4.1 has as "up to server
policy" is in some sense an anti-DoS measure, to keep the server from
having to dedicate potentially "unlimited" resources to handling a
client request that is authenticated only by the TLS connection.

As mentioned above, we should have a bit of discussion of the
security/privacy considerations of the information sent with the
security events, particularly when sent to an unauthenticated user.

   The extension leaves the password (<pw> element) and new password
   (<newPW> element) minimum length beyond 6 characters and the maximum
   length up to sever policy.  The server SHOULD enforce minimum and

nit: I don't understand what "minimum length beyond 6 characters means".

Section 10

Why is RFC 2119 Normative but RFC 8174 Informative?  Together they are
both BCP 14, and I don't see why they would be treated differently.
[ed. I see Éric already asked and got a response.]

---

From: "Gould, James" <[email-masked]>
Date: Thu, 23 Jan 2020 19:45:03 +0000

Benjamin,

Thank you for your thorough review and thoughtful feedback.  My responses are embedded below.

--

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

On 1/22/20, 9:31 PM, "regext on behalf of Benjamin Kaduk via Datatracker" <[email-masked] on behalf of [email-masked]> wrote:

    DISCUSS:

JG - The goal of draft-ietf-regext-login-security is to enhance the security of RFC5730 using an EPP extension, which means that it is evolutionary and not revolutionary.  The introduction describes the key security issue with RFC5730 with the hard limit of a 16-character maximum password length, which draft-ietf-regext-login-security addresses in the least impactful method possible.  Adding features that make security events more transparent in the protocol by adding the ability to pass the client user agent, to help the server identify potential security events, and by adding the ability for the server to proactively return security events to the client, are security enhancements not associated with RFC5730 being insecure.  There was discussion on the mailing list related to the use of alternative authentication approaches for EPP, but those proposals need to mature into something concrete for discussion.  Please forward any ideas that you have to the regext mailing list.

    understanding.

JG - The use of free-form strings (e.g., string, token, normalizedString) is nothing new with XML and all of the elements and attributes of draft-ietf-regext-login-security have been fully considered for the level of specification.  There are many examples in the EPP RFCs, including the definition of the <pw> and <newPw> elements in RFC5730, where the format is left up to server policy.  Inclusion of the 16-character maximum length in RFC5730 is an example of a policy that was injected into the RFC5730 that needs to be fixed based on the latest security practices.  The intention of draft-ietf-regext-login-security is to extend RFC5730 without adding new policy constraints that would hinder its adoption in the industry and would support future security policies.  The sentence "If non-ASCII characters are supported with the plain text password, then use a standard for passwords with international characters, such as the OpaqueString PRECIS profile in [RFC8265]" was added to draft-ietf-regext-login-security to address the PRECIS profile concern with the AD.

JG - One of the goals of this extension is to enhance RFC 5730 by overriding the <pw> and <newPw> elements with the use of this sentinel value and support for passing the new <loginSec:pw> and <loginSec:newPw> elements without the 16-character maximum length restriction.  There is no need to mark draft-ietf-regext-login-security as updating RFC 5730, since a client will know that the server is implementing draft-ietf-regext-login-security based on the inclusion of the urn:ietf:params:xml:ns:epp:loginSec-1.0 extension namespace returned in the EPP greeting and the server will look for the sentinel value and the extension in the login command.  This is a natural form of an EPP extension that RFC 5730 fully supports.

    COMMENT:

    listing.

JG - Are you proposing a change here?  See my response to your first Discuss point.

    Section 1

    change in response.)

JG - Thanks for the references, I'll take a look at them.

JG - Thanks for the feedback.  I believe that the definition of the Event as the first section (section 3.1) of the Object Attributes section (section 3) is the appropriate location.

    Section 2

JG - There was much discussion on the mailing list about this section and the appropriate normative language.  Paragraphs 2 and 3 do propose a method with meeting the requirement in paragraph 1.  I do believe that SHOULD is appropriate in this case.

    version="1.0"'''...

JG - There is no mention of version number in RFC 5730, but it is general understood in regext that the version numbers always increase.  Do you believe something needs to be added explicitly in section 2, such as adding the sentence "A newer version of the extension is expected to use an XML namespace with a higher version number than the prior versions." at the end of the first paragraph?

    Section 3.1

    element"?)

JG - I view the <loginSec:event> element as an noun (or object) in its own right that is contained in a list.  Is the issue associated with the sentence "There MAY be multiple events returned that provide information for the client to address." being in the middle of a paragraph describing the event object?  How about changing that sentence to read "The <loginSec:event> element is contained in a list of one or more elements in the <loginSec:loginSecData> element, so there MAY be multiple events returned that provide information for the client to address."?

           [...]

JG - The "password" and "certificate" types are based on known cases of implementing a password-expiry policy and proactively informing clients of expiring client certificates.  There has been cases where clients were unaware of an expiring client certificate that caused a client-side connectivity outage, so now the server can inform them of an expiring client certificate.  Others cases would fall into the "custom" security event.

JG.- The "exDate" attribute can be used with multiple event types.  For example, the server could decide to deprecate TLS ciphers ("cipher") or protocols ("tlsProtocol") and specify an expiry of when they will be removed, which would result in a connection failure.  The " exDate " attribute could also be used with the “custom” event, where it may not result in connection or login failure.  The purpose of the MAY is to make it clear that the expiry may result in an failure (connect or login), but there are cases where it will not result in a failure.  The <loginSecPolicy:errorAction> element in draft-gould-regext-login-security-policy provides an example of defining the policy of what occurs at expiry for an event type, which includes the possible values of "connect" for a connection failure, "login" for a login failure, or "none" for no failure.

JG - How about changing the "error to" sentence to read "At expiry there MAY be a connection failure or MAY be an login failure."?  A similar change can be made to the following example sentence with "An example is an expired certification that will result in a connection failure or an expired password that may result in a login failure.".  Do you agree with these changes?

    of TLS ciphersuites

    multiple choices).

JG - Thanks for the reference to the IANA TLS cipher suites.  I have personally not seen TLS implementations consistently use the IANA TLS cipher suites, so that is a good reference but unfortunately not universally used.  I agree that that value will not be automatically parsed and processed by the client, but will most likely will be logged and included in an alert for manual investigation.  The value returned based on the TLS implementation should provide some meaning to the client; although mapping to the client-side TLS cipher suite names is likely necessary and may require help from the server to interpret out of band.  What I have seen are string values similar to the Description field in https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4, but again I have not seen consistency across the TLS implementations.  How about doing the following to address this:

  1.  Update the “cipher” type description to read:

a.       Identifies the use of an insecure or deprecated TLS cipher suite.  The “name” attribute MUST be set with the name of the cipher suite, which is free-form and is not expected to be parsed and automatically addressed by the client.  An example of cipher suite names can be found in the TLS Cipher Suites of the Transport Layer Security (TLS) Parameters IANA registry [link to https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4].

  1.  Update the “tlsProtocol” type description to read:
     *   Identifies the use of an insecure or deprecated TLS protocol.  The “name” attribute MUST be set with the name of the TLS protocol, which is free-form and is not expected to be parsed and automatically addressed by the client.

Thoughts?

    that's a nice touch!

JG – The dates can be revised to 2020 instead of 2018.

    Section 3.2

    that's overused.)

JG – On the use of sentinel or constant, I prefer the use of constant.  I can modify the <pw> reference and the <newPw> reference in 3.2 to read:

  1.  When the [RFC5730] <pw> element contains the predefined value of “[LOGIN-SECURITY]”, the <loginSec:pw> element overrides the <pw> element.
  2.  Similarly, when the [RFC5730] <newPw> element contains the predefined value of “[LOGIN-SECURITY]”, the <loginSec:newPw> element overrides the <pw> element.

    Section 3.3

JG – The limitation is with XML schema and is not specific to EPP.  This is boilerplate text in the EPP RFC’s (e.g., https://tools.ietf.org/html/rfc5731#section-2.4, https://tools.ietf.org/html/rfc5733#section-2.7, https://tools.ietf.org/html/rfc5732#section-2.4).

    Section 4.1

JG – This is not tracking or profiling individual users, but is a system-to-system interface.  Do you have any recommendations for what would be discussed for a system-to-system interface?

JG – I will make that change.

    Why is it optional?

JG – It’s optional, since the user may still be using the <pw> element from RFC5730, which supports passwords up to 16-characters.  When the minimum password length policy is greater than 16-characters, than it would be required by server policy.

JG – The working group discussed this in detail.  The agreement was to match the existing minimum in RFC5730.  It would be up to server policy to set a higher minimum.  The maximum length of 16 characters from RFC5730 was removed in draft-ietf-regext-login-security.

JG – This is explicitly stating what is done by the XML parsing when using the XML schema “token” type.  I agreed to add this based on working group feedback.

JG – “only be used” means “only be set” or even “only be included”.  In other words, the client MUST only set the <loginSec:pw> element when the “[LOGIN-SECURITY]” value is set in the <pw> element.    The server would use the RFC5730 “<pw>” element, based on the language in section 3.2.  This is the corresponding language for the client to not provide two passwords in the login command.  Do you prefer “only bet set” over “only be used”?

JG – There was discussion around PRECIS on the mailing list and this language was working out with the AD.

JG – The encoding in the XML header applies to the entire XML packet.  The encoding chosen would need to support non-ASCII data (e.g., “UTF-8”) and the XML parser would need to support that encoding to unmarshal the data correctly.  The encoding in the XML header and the characters allowed for the passwords is not new for EPP RFC 5730, where draft-ietf-regext-login-security is enabling the use of longer passwords.  As noted previously, the reference to the PRECIS profile in [RFC8265] was added to address the case where a server does support non-ASCII passwords based on working with the AD.

JG – The clTRID is not a security credential but is used as an Asynchronous Completion Token (ACT), so there is nothing wrong with using “ABC-12345”.

JG – This can be updated to a newer Mac OS, such as 10.14 or 10.15.

    examples)

JG – Agreed, but it provides better context for the element than a high-entropy value.

       conditions:

    conditions hold".

JG – This change can be made.

       requirements:

JG – Good catch!  I’ll change that the exDate to 2018-03-24.  Actually, it will be 2020-03-24 based on the earlier agreement to change 2018 to 2020 throughout the draft.

JG – Agreed, but inclusion of the events would be up to the security policy of the server.  The extension supports returning it if the server needs to.  Below, I proposed adding a sentence associated with this in section 8.

JG

    Section 8

JG – Agreed, based on the feedback from Roman, The leading sentence “The Security Considerations of [RFC5730]<file:///Users/jgould/projects/github/login-security-extension/draft-ietf-regext-login-security.html#RFC5730> apply in this document, and this document enhances these considerations.” will be added to section 8.

JG – Agreed, are you asking for any change for this?

JG – How about adding the following at the end of the last paragraph in section 8:

“The server returning of security events to unauthenticated users needs to take into account the security/privacy issues of potentially returning information to potential attackers.”

JG – “beyond” can be changed to “greater than”, so it would read “…minimum length greater than 6 characters…”

    Section 10

JG – Yes, that will be addressed, thanks!

    _______________________________________________

    regext mailing list

    [email-masked]

    https://www.ietf.org/mailman/listinfo/regext

---

From: Benjamin Kaduk <[email-masked]>
Date: Thu, 23 Jan 2020 13:08:36 -0800

Hi JG,

Continuing inline...

> Thank you for your thorough review and thoughtful feedback.  My responses are embedded below.

Thanks for pointing to the list discussion of potential alternative
authentication approaches, and I'll see if I can make time to write
something down.  I'm not opposed to publishing an evolutionary improvement
while revolutionary changes are immature, but I do think that the document
should be more explicit about the nature of the need.  Yes, artificial
password-length limitations are bad and I'm happy to see this work to
remove them from EPP, but are there particular security deployment
considerations driving this, such as a desire to support memorable
passphrases that contain sufficent entropy?  From a purely
information-theoretic perspective, if we limit ourselves to the ASCII
alphabet from 0x20 to 0x7e, 16 charcters gives roughly 104 bits of entropy
available, which is not catastrophically bad; in combination with the
prerequirement for TLS client-certificate authentication, a server could
block or rate-limit brute-force guessing attacks and achieve a level of
security that is reasonable for many if not most web-available services
today.  Even if the perceived need is just "artificial limitations on
password length are detrimental to future evolution in security practice"
(which seems unlikely to me based on my bayesian prior), it seems worth
saying.  I suspect that there's more motivation in play, and would like to
better understand it.

> JG - The use of free-form strings (e.g., string, token, normalizedString) is nothing new with XML and all of the elements and attributes of draft-ietf-regext-login-security have been fully consider…

Thanks for the extra context, but I don't think that this addresses my
concern (and continue to hope that the responsible AD will chime in).
Specifically, if we assume that a given (client/server) implementation will
expect to be able to talk to multiple (server/client) implementations and
that a user might end up needing to enter their password at multiple client
machines (e.g., with different client implementation or OS), then the
password-normalization situation quickly becomes complicated when non-ASCII
is allowed.  Different input methods and OS implementations will produce
different representations of the "same password" in the eyes of the user,
and getting all parties to implement the same normalization procedure is
non-trivial.  If we mandate a single normalization procedure for everyone
to implement, then the expectation of smooth interoperability is much
greater than what the current document gives us, as there is only a single
thing to implement, no need for dispatch logic in clients based on server
preference/configuration, no risk of subtle bugs in less-commonly-used
algorithms in a given implementation, a single thing to build effective
test cases for, etc..

I don't particularly mind (or have become acclimated to) the normal EPP
"custom" mechanism for extension that does not have strong protections
against collision or discoverability for precise semantics (what Alissa's
Discuss was covering), and can tolerate leaving the precise semantics of
some elements out of scope (particularly when those elements are indicated
as only intended for human consumption, as Roman's Discuss was covering),
but I think that password normalization is qualitatively different and "one
true normalization method" is best for the protocol ecosystem.

> JG - One of the goals of this extension is to enhance RFC 5730 by overriding the <pw> and <newPw> elements with the use of this sentinel value and support for passing the new <loginSec:pw> and <log…

I don't think this quite addresses my concern, which I will try to phrase
more concretely: what is the expected behavior if a client that does not
implement this extension tries to use the literal value "[LOGIN-SECURITY]"
in a traditional <newPW> element, when the server does implement this
extension?  If the answer is "the server accepts the new password and
proceeds to use it for future authentication" then we get a subtle and hard
to diagnose mess when the user moves to a different machine/implementation
or upgrades their software; if the answer is "the server rejects the
password as reserved", what existing part of 5730 allows the client to
accept that?

There's significant latent risk in the protocol transmitting unmodified
passwords, and in the server having a local database of (e.g., salted and
hashed) password verifiers, or worse, plaintext passwords).  RFC 5730 does
not really mention these risks other than mandating transport-layer
protection, and I am proposing that we correct that omission here, since
the password is an integral part of the proposed new mechanism.

> JG - Thanks for the references, I'll take a look at them.

[As for Roman's mention of (Co-)SWID, this is mostly just for information,
and not necessarily expected to result in a change to this document.]

> JG - There is no mention of version number in RFC 5730, but it is general understood in regext that the version numbers always increase.  Do you believe something needs to be added explicitly in se…

I wouldn't be opposed to seeing such text, though I'm also pretty amenable
to suggestions that 5730 was the right place to discuss versioning and it
would be awkward to try to start doing so in this document.

> JG - I view the <loginSec:event> element as an noun (or object) in its own right that is contained in a list.  Is the issue associated with the sentence "There MAY be multiple events returned that…

The (perceived) issue is with "The <loginSec:event> element", in terms of
how the single distinguished entity (to justify "the" vs. "a") is
identified.  It seems that the intent is to refer to that element in the
abstract, but as you note the preceding discussion suggests a local context in which
there is a sequence of sibling <loginSec:event> elements and so it's hard
to pick out which specific one is being discussed from that sequence as
opposed to reverting back to the generic/abstract case.
There are many potential resolutions to this (nit-level) issue, ranging
from very small changes such as "Each <loginSec:event> MAY [...]",
"<loginSec:event>s MAY [...]", "The, <loginSec:event>s MAY [...]", etc., to
broader changes like your proposal.  Even with your proposal "The
<loginSec:event> MAY" reads oddly to me, perhaps because we do use
"element" elsewhere in the document ("The <loginSec:userAgent> element MUST
contain", ...), but I have no particular reason for thinking that "reads
oddly" is true for anyone other than me.

> JG - The "password" and "certificate" types are based on known cases of implementing a password-expiry policy and proactively informing clients of expiring client certificates.  There has been case…

Oh, I totally support having events with these semantics!  I would just
have used a less general name for them, but that's just me :)

> JG - How about changing the "error to" sentence to read "At expiry there MAY be a connection failure or MAY be an login failure."?  A similar change can be made to the following example sentence wi…

Those sound like improvements, thanks.  I'll defer to you about "MAY" vs.
"may".

>      *   Identifies the use of an insecure or deprecated TLS protocol.  The “name” attribute MUST be set with the name of the TLS protocol, which is free-form and is not expected to be parsed and a…

Thanks, this looks good to me.  (There may be other fields that would
benefit from a similar treatment, which I attempted to allude to in a
Discuss point, though I do not have any concrete examples in mind right
now.)

>   2.  Similarly, when the [RFC5730] <newPw> element contains the predefined value of “[LOGIN-SECURITY]”, the <loginSec:newPw> element overrides the <pw> element.

Thanks!

> JG – The limitation is with XML schema and is not specific to EPP.  This is boilerplate text in the EPP RFC’s (e.g., https://tools.ietf.org/html/rfc5731#section-2.4, https://tools.ietf.org/html/rfc…

Ah, so I'm bitten by "XML Schema" being self-plural.  Thanks for the
reminder.

> JG – This is not tracking or profiling individual users, but is a system-to-system interface.  Do you have any recommendations for what would be discussed for a system-to-system interface?

Is it appropriate to say something like "The user-agent information
represents a system-to-system interface, and any given client system may
have multiple users, or any given user might use multiple systems.  Client
systems tend to be at stable locations, so user-agent identifiers are not
expected to provide any ability to track individual users or classes of
user"?

> JG – The working group discussed this in detail.  The agreement was to match the existing minimum in RFC5730.  It would be up to server policy to set a higher minimum.  The maximum length of 16 cha…

Okay, I will not push further to break with the defaults from 5730 in this
document.

> JG – This is explicitly stating what is done by the XML parsing when using the XML schema “token” type.  I agreed to add this based on working group feedback.

This is sounding like (assuming <?xml encoding="UTF-8">) the leading and
trailing whitespace that will be stripped is indeed different from the
internal whitespace that collapses to a single #x20, and thanks for the
reminder about XML parsing behavior; assuming we're all on the same page
about that, I don't see particular need for text changes here.

> JG – “only be used” means “only be set” or even “only be included”.  In other words, the client MUST only set the <loginSec:pw> element when the “[LOGIN-SECURITY]” value is set in the <pw> element.…

That would be my personal preference, but your preferences will overrule mine
here.

> JG – There was discussion around PRECIS on the mailing list and this language was working out with the AD.

I have more confidence in the discussions of the PRECIS WG than the REGEXT
WG regarding the usage of PRECIS profiles.  Unfortunately, I am not an
expert on the PRECIS discussions and am looking for help from someone who
is.

> JG – Agreed, are you asking for any change for this?

It would be reasonable to mention if you want, though I am not specifically
asking for it to be included.

> “The server returning of security events to unauthenticated users needs to take into account the security/privacy issues of potentially returning information to potential attackers.”

Thanks.

> JG – “beyond” can be changed to “greater than”, so it would read “…minimum length greater than 6 characters…”

Er, I think that the "minimum length" is 6 and that it's password lengths
in general that are "greater than 6 characters".  So my suggestion would be
s/beyond/at/.

Thanks,

Ben

---

From: "Gould, James" <[email-masked]>
Date: Fri, 24 Jan 2020 21:06:33 +0000

Ben,

Thanks for the quick response.  My responses are included below prefixed with JG2.

--

JG

James Gould

Distinguished Engineer

703-948-3271

12061 Bluemont Way

Reston, VA 20190

On 1/23/20, 4:09 PM, "Benjamin Kaduk" <[email-masked]> wrote:

    Hi JG,

    Continuing inline...

    better understand it.

JG2 - The only deployment consideration is being able to set passwords beyond the 16 character limit of RFC 5730 for the critical domain name registry systems.  Yes, there is multi-factor authentication with EPP (user name/password and client certificate, and optionally client IP address), but there is the operational need to enhance the security of the passwords with longer lengths and higher entropy (e.g., at least 128 bits).  Are you looking for a sentence being added to the introduction that identifies the problem more explicitly, such as:

EPP [RFC 5730] includes a maximum password length of 16 characters that inhibits implementing stronger password security policies with higher entropy.

    test cases for, etc..

JG2 - There is no end user entering their password but client machines using their stored password to authenticate to server machines.  I see absolutely no advantage for EPP clients using non-ASCII passwords, but there may be EPP clients and EPP servers in the wild that do support non-ASCII passwords.  I don't believe that we want to define new requirements in draft-ietf-regext-login-security that would invalidate existing implementations of EPP RFC 5730.  The PRECIS profile language added to draft-ietf-regext-login-security was meant to new guidance to use a standard for passwords with international characters, such as the OpaqueString PRECIS profile in RFC8265.

    accept that?

JG2 - In the case of an invalid password, such as the sentinel value "[LOGIN-SECURITY]", or a password that does not meet the server password complexity requirements, my recommendation is for the server to return a 2200 "Authentication error" whether the client supports the Login Security Extension or not.  If the server returned a successful response, the client may assume that the new password was set, which is not the case.  If the client supports the Login Security Extension, the server can return the "newPw" security event explicitly letting the client know why the login failed.  A client that does not support the Login Security Extension would not receive the explicit reason for the error in a machine readable form.  The server can return a human-readable reason in the RFC 5730 <msg> element of the error response.  To address your concern, do you want the last sentence of section 3.2 to read:

The server MUST NOT allow the client to set the password to the value "[LOGIN-SECURITY]" by returning a 2200 "Authentication error" error.

JG2 – Are you looking to add something to the Security Considerations section for this?  Do you have any recommended text?

JG2 – I believe adding the text in section 2 is relevant, since it is referring to the versioning of the Login Security Extension.

JG2 – Yes, I understand your concern.  The intent of that section is to fully describe an individual security event, but indicating that the security event is contained in a list is relevant to the implementer.  Typically in the EPP extensions, an element is described similar to the following.  I can remove “There MAY be multiple events returned that provide information for the client to address." If it is causing too much confusion or I can update it to my revised proposal of "The <loginSec:event> element is contained in a list of one or more elements in the <loginSec:loginSecData> element, so there MAY be multiple events returned that provide information for the client to address.".  At this point, I’ve included the revised sentence in the draft.

<loginSec:event>:
One or more <loginSec:event> element defined in section 3.1.

JG2 – The intend of section 3.1 is to describe the individual <logicSec:event> element.

    "may".

JG2 – I’ll go ahead and make the change keeping the normative MAYs.

    now.)

JG2 – I believe the other two types that need similar treatment would be the “password” and the “certificate” types, where it indicates that the “exDate” attribute is used, but it doesn’t explicitly state that it MUST be set.  I’ll add the following sentence to both the “password” and the “certificate” types:

The ”exDate” attribute MUST be set with the [password|certificate] expiry date and time.

    Thanks!

    reminder.

    user"?

JG2 – I would simply it a little bit by saying “The user agent information represents the client system of a system-to-system interface, so the user agent information MUST NOT provide any ability to track individual users or classes of users.”  I’ll place this into the Security Considerations section.

    document.

    here.

JG2 – I’ll update it to “only be set”.

    is.

JG2 – We did have discussions around the PRECIS profiles and I believe that the text added in working with the AD is a nice balance.

JG2 – Ok, I’ll leave it as is.

    Thanks.

    s/beyond/at/.

JG2 – Actually, it’s setting a minimum length that is greater than the protocol minimum of 6 that is up to server policy.  The server could of course use the protocol minimum, but adjusting the minimum higher than the protocol minimum is a server policy decision.  I believe that changing “beyond” to “greater than” is the correct change if “beyond” is not clear.

    Thanks,

    Ben