Subject: Re: [regext] draft-ietf-regext-login-security

From: "Patrick Mevzek" <[email-masked]>
Date: Tue, 02 Jul 2019 02:10:34 -0500

On Fri, Jun 21, 2019, at 08:22, Antoin Verschuren wrote:
> We believe the draft draft-ietf-regext-login-security still has an open 
> issue from Patrick Meczek where James response should be confirmed, but 

I have reviewed past exchanges and I do not think that there is anything open left:
I remain in disagreement on various points[1] hence I will not formally
approve it, but I won't either block its advancement.

So, "all fine" for me.

Minor in 4.1: "MUST be included in the response based on the following conditions"
you should probably emphasize that there is an "AND" between the two points, not an OR.
Probably obvious but since there are other discussions abount unannounced extensions
it is probably better to be more specific.

[1] Among other things
(they already have been discussed or not worth discussing, so  I just mention them here for archives, not to open the debate):

- I dislike the use of a specific hardcoded string such as LOGIN-SECURITY
(IETF even has a specific RFC about choosing "random" names, which was followed
by various cases, like for the xn-- in IDNs. See RFC 3797/2777 or its use for IDNs at http://www.ccwhois.org/mailarchive/cctld-discuss/vol05/0096.html)
- the extension mixes different things (new password scheme, letting the client
identify itself better like user-agent in HTTP, letting the server give
back more structured information about both passwords and TLS... this should
be in 3 extensions, not one)
- discussing about TLS versions being insecure or not would probably need
a reference to RFC8446 and draft-ietf-tls-oldversions-deprecate
- as for reporting problems at the TLS stack was there a discussion on why/when this
should happen at the EPP level instead of directly at the TLS level?
Specifically because there can be setups where the TLS terminations is in front
of the EPP application servers so a server wanting to forbid some connections,
for problems at the TLS level may be technically unable to do it at the EPP level.
- a lot of things are not defined. For example for ciphers, what is the value field?
Is that TLS ciphers from IANA repository? something else?
Not defining things like this is easier to bootstrap the extension usage, but at the
end of the day will make it less interoperable and complicate registrars life.
For insecure TLS versions, what will be the format?
TLS 1.0
TLS_1.0
TLS_1_0
TLSv1.0 like the example given
0x0301
etc.

- the level could have from the get go accepted typical logging levels, so like info/debug/trace/notice in addition to current warning/error
- there is no discussion if the server SHOULD/MAY/MUST refuse the login (return code > 2000)
if there is any event at level="error".
- "The client SHOULD NOT decrease the security of a new password by
   decreasing the length of the current password." that does not explain how the
server should react then? Allow it always? Deny it? Let it decide per local policies?
- a mention/discussion of RFC7613 would seem appropriate
- more generally working today on authentication should be based on SASL and
we should open things better and with more extensibility. This extension is just
piggybacking on the current scheme which creates its own range of interoperatbility
problems.

-- 
  Patrick Mevzek
  [email-masked]

---

From: Joseph Yee <[email-masked]>
Date: Wed, 10 Jul 2019 18:13:55 -0400

Antoin,

I would like to request for 5-10 minutes to briefly discuss a new
submission on registration report definition.  I can't upload the draft now
as it's closed now, will submit the draft when it's reopened.  I attached
the draft here for reference.

Thanks
Joseph

On Fri, Jun 14, 2019 at 9:32 AM Antoin Verschuren <[email-masked]> wrote:

> This is a request for agenda items for IETF 105 in Montreal.
> If you have any agenda items please send them to the list.
>
> As you may have seen, we have published a new milestone list.
> The order of agenda items will follow that list.
> The chairs want to remind the working group that we have a milestone date
> for one document in July.
> If you need to focus, then focus on reviewing that document (
> https://datatracker.ietf.org/doc/draft-ietf-regext-login-security/)
>
> We have a 2 hour slot, so we should have enough time for additional
> presentations, but let’s do the work first.
>
> Regards,
>
> Jim and Antoin
>
> - --
> Antoin Verschuren
>
> Tweevoren 6, 5672 SB Nuenen, NL
> M: +31 6 37682392
>
>
>
>
>
>
> Op 7 jun. 2019, om 15:13 heeft IETF Meeting Session Request Tool <
> [email-masked]> het volgende geschreven:
>
>
>
> A new meeting session request has just been submitted by James Galvin, a
> Chair of the regext working group.
>
>
> ---------------------------------------------------------
> Working Group Name: Registration Protocols Extensions
> Area Name: Applications and Real-Time Area
> Session Requester: James Galvin
>
> Number of Sessions: 1
> Length of Session(s):  2 Hours
> Number of Attendees: 50
> Conflicts to Avoid:
> First Priority: dnssd dnsop dprive
> Second Priority: saag oauth doh
>
>
>
> People who must be present:
>  James Galvin
>  Barry Leiba
>  Antoin Verschuren
>
> Resources Requested:
>
> Special Requests:
>  Please avoid any DNS related BOF&#39;s.
>
> ---------------------------------------------------------
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>
>
> _______________________________________________
> regext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/regext
>

---

From: "Gould, James" <[email-masked]>
Date: Fri, 12 Jul 2019 21:36:16 +0000

Patrick,

Thanks for confirming the lack of an open item for draft-ietf-regext-login-security.  I respond to your feedback embedded below.

—

JG

James Gould

Distinguished Engineer

[email-masked]

703-948-3271

12061 Bluemont Way

Reston, VA 20190

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

On 7/2/19, 3:10 AM, "regext on behalf of Patrick Mevzek" <[email-masked] on behalf of [email-masked]> wrote:

    So, "all fine" for me.

JG - Agreed that this is an AND and not an OR.  Maybe this can be addressed by modifying the sentence to read "Upon a completed login command (success or failed), the extension MUST be included in the response based on both of the following conditions:"

    [1] Among other things

JG – Thank you for listing your items.  I include my responses for consideration by the working group.

JG - EPP RFC 5730 requires a minimum of 6 characters and a maximum of 16 characters for the pw and newPW elements, so something needs to be set in the pw element at a minimum.  The use of the "LOGIN-SECURITY" placeholder value is meant to be explicit about overriding the value with the corresponding value in the extension.   A random value would make it less clear.  RFC 3797/2777 describes a method of random selection, which I don't believe is applicable here.

    back more structured information about both passwords and TLS... this shouldi

JG - All of these elements are associated with security and are extensions to the EPP login command or response, so it is cleanest to include them in a single EPP extension.

JG - The TLS versions supported is a decision for server policy and is not outlined in the EPP extension.  The EPP extension enables the server to inform the client of the deprecation of a negotiated TLS version and the EPP extension does not define or recommend any specific deprecation policy.  I don't see making a reference to RFC 8446 or draft-ietf-tls-oldversions-deprecate as needed to support what is defined in draft-ietf-regext-login-security.

    TLS 1.0

    TLS_1.0

    TLS_1_0

    0x0301

    etc.

JG - The tlsProtocol security event is meant to communicate the deprecation of a TLS protocol that was negotiated when connecting to the EPP server.  You need to first be capable of connecting to the server to send the login command, so the tlsProtocol security event will enable the server to proactively let the client know that the TLS version negotiated is deprecated with an optional date when the TLS version will not be supported.  If the TLS version is not supported, the TLS handshake will fail, and draft-ietf-regext-login-security will not be of use.  The termination of the EPP TLS connection is typically done with an EPP-aware gateway / server, but if a proxy is used that is incapable of passing the TLS connection information to the EPP application server, the EPP server will not be capable of supporting the certificate, cipher, or tlsProtocol security events.  An EPP server does not need to support all of the draft-ietf-regext-login-security security event types.  The draft-gould-regext-login-security-policy is meant to inform the client what security events are supported along with the security event policies.  There is no standard related to the format of the TLS versions and the ciphers that I'm aware of, so the value returned for a tlsProtocol and cipher security event is up to the TLS stack chosen by the server.

JG - The point of the security event is meant to identify an issue and is not meant for other levels that are typically used for logging, such as info/debug/trace/notice.

JG – The security event can be associated with multiple security use cases (connection, login, and statistics) that is up to server policy to define what an "error" level results in.  The SHOULD/MAY/MUST and the refusal of the login is server policy and not applicable to draft-gould-regext-login-security.  The draft that does define the server policy is draft-gould-regext-login-security-policy.

JG - I don't believe the server will even know, assuming that they're storing the password as a hash.  I believe the server should define the format requirements of the new password (e.g., max, min, characters) and not attempt to enforce this security consideration.

JG - I reviewed RFC 7613 and I really don't see it's applicability to draft-ietf-regext-login-security, since the format of the passwords is up to server policy.  Use of a specific password format that supports International characters and the PRECIS framework can be defined in a BCP, where section 8.1 of RFC 7613 states that the ability to include a wide range of characters for creating a strong password with high entropy ought to be weighed against the possible need to reproduce them on various devices using various input methods.  Weighing the options is a server policy decision and not in scope for draft-ietf-regext-login-security.

    problems.

JG - EPP RFC 5730 does define the use of PLAIN SASL, which is what draft-ietf-regext-login-security is extending to support longer passwords.  Piggybacking on the current scheme enhances the interoperability.  If you have a proposed alternative scheme for EPP authentication, I recommend that you define it in an Internet Draft for consideration.

    --

      Patrick Mevzek

      [email-masked]

    regext mailing list

    [email-masked]