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

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

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

[e-mail]



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" <[e-mail] on behalf of [e-mail]> wrote:







    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.



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

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



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



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



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.



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

    be in 3 extensions, not one)



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.



    - discussing about TLS versions being insecure or not would probably need

    a reference to RFC8446 and draft-ietf-tls-oldversions-deprecate



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.



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



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.



    - the level could have from the get go accepted typical logging levels, so like info/debug/trace/notice in addition to current warning/error



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.



    - there is no discussion if the server SHOULD/MAY/MUST refuse the login (return code > 2000)

    if there is any event at level="error".



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.



    - "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?



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.



    - a mention/discussion of RFC7613 would seem appropriate



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.



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



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

      [e-mail]



    _______________________________________________

    regext mailing list

    [e-mail]

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