Re: [regext] review of draft-ietf-regext-login-security-03

"Gould, James" <jgould@verisign.com> Wed, 03 April 2019 22:20 UTC

Return-Path: <jgould@verisign.com>
X-Original-To: regext@ietfa.amsl.com
Delivered-To: regext@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 108F112015B for <regext@ietfa.amsl.com>; Wed, 3 Apr 2019 15:20:09 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.299
X-Spam-Level:
X-Spam-Status: No, score=-4.299 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, HTML_MESSAGE=0.001, RCVD_IN_DNSWL_MED=-2.3, SPF_PASS=-0.001, URIBL_BLOCKED=0.001] autolearn=ham autolearn_force=no
Authentication-Results: ietfa.amsl.com (amavisd-new); dkim=pass (2048-bit key) header.d=verisign.com
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id 82sKND5U0qlK for <regext@ietfa.amsl.com>; Wed, 3 Apr 2019 15:20:05 -0700 (PDT)
Received: from mail2.verisign.com (mail2.verisign.com [72.13.63.31]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by ietfa.amsl.com (Postfix) with ESMTPS id 0446E120149 for <regext@ietf.org>; Wed, 3 Apr 2019 15:20:04 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=44770; q=dns/txt; s=VRSN; t=1554330005; h=from:to:date:message-id:references:in-reply-to: mime-version:subject; bh=VD+UcgTbhQkQWt9fKwUpafvOYy0R8EhESI6i3kQA7iY=; b=RWryq9X/JWFXckWhp/KhGYVE3QbZzd2nImFGtxu6vs2Xli4QMDEck9nX RsUuKt2cIb/Mr7w8IVDtYhgZ0NxkMibZDRGLcLzdQdIyDvmfjnpgqanq0 mBaTKxT0+wYqd5w99gDetqV1O2WLTMQOptssQK5zLmeOqdU3HOOFjh2W1 O7ghys+/ufqnUoi3ywID5/rBZRmRbki13085Ua7OJv9HIg93L1rJSAUpY X/Rh5Xm236xUNtK2TsWfcNlTmE5TWMw8vU+0xYb5KdMBo/cMCs6tS/RV/ riall4qBnjCIAnxFtV78T7Nb/hKeXAxx9tYiOqtfeuQ7nkl4z8bWhW2pd w==;
X-IronPort-AV: E=Sophos;i="5.60,306,1549929600"; d="png'150?scan'150,208,217,150";a="7476924"
IronPort-PHdr: 9a23:KtkVnhWkO3SsYsEeE+Y1CJpX7ZLV8LGtZVwlr6E/grcLSJyIuqrYZRSOtadThVPEFb/W9+hDw7KP9fy5ACpYvd3Z7DhCKMUKC0Zdz51O3kQJO42sMQXDNvnkbig3ToxpdWRO2DWFC3VTA9v0fFbIo3e/vnY4ExT7MhdpdKyuQtaBx8u42Pqv9JLNfg5GmCSyYa9oLBWxsA7dqtQajZFtJ6os1xfFuGdEdutZyW90Kl+YghLw6tut8JJ5/Clcpu4t+9RcXanmeqgzUKBVAikhP20p/sPgqAPNTRGI5nsSU2UWlgRHDg3Y5xzkXZn/rzX3uPNl1CaVIcP5Q7Y0WS+/76hwUx/nlD0HNz8i/27JjMF7kb9Wrwigpxx7xI7UfZ2VOf9jda7TYd8WWWxMVdtXWidcAI2zcpEPAvIBM+hGsof9u1UAoxiwBQauCuzvyyNHiXDt0K0gz+ghFBvL0BA6Et8MtnnfsdX7NL0VUeCw1KTEwzTNb/RL2Tf59YfEag0qr/WWUrJ1b8XR0kcjHB7Cg1WSpozlOC6V1uAQvGWA8epvS/ivi288qwFwrTivwN0ghZXOhoIQ013J8zhyzogyJd29UkF7YNikHYNOty6ELYt2Q9giQ2BnuCY80LEJpZm7fC0SxJQ52RHfcf2Hc5OJ4hLsUuaRIDF4i25/dL2jgBay9FCsyvbyV8m1zFZFsipFnsPQuXANzxDT69aISudz/ku73jaPzQ/T5+dZKk43jarWM4MtzqIqmpYOs0nOEDX6lFj2gaKYbEkp9eyl5/z6brn6vJOQKo15hh3kPqgzlcGyAv40PhUNUmSD9+Szyr7u8VH8TbhPlPI7ka3Uv4vfKMkVuKK2Hg5Y34M45Bu7Djqr0tEVkHcJIV9HZR2KiZXiNUvUL/DiF/i/hkyhkDJsx//bILLsGo7NLn3fkLf5erZ99lJcxBIzzd9B45JUDakMLe/vVEHpqdDXDgc3PQO1zOr7FtlxzJ0eVn6IAq+DKKPeq0WH6f81L+mSfo8VozD9J+I56P7piH81gV4dfa+30psLcH20A+hqL1+EbXfujNoNC3oGswowQeDwh1CPVSZfZ3OoUKI94jE7BpimDYDGRo21gryB0yC7HoBSZm9bEV2MD2nnd5+FW/cXaSKSLclhniYYWrimTo8tzQuuuxPiy7p7MurU/TUVtZf529hv++3TlBcy+SZoAMuHyGGCVWd0nmQWRzAsx61/ukJ8ylaf0adkg/xUD8Bc5/NRWAcgKZHc1/B6C8z1Wg/ZZNeGVlmmTcupADEtVd8xwsEBY1pzG9m4iRDDxSWqUPcpkOnBAZUu7qPamXP4PM97zGjP/LI+jkUtQo1ENSfu0qt27RTSAcjCml6QkaG0fIwHwy/R/2fFxmrY+AkSSgN/XLXZdXESekWQqs72rAuWVbKhBKQ7GgpM1cDELbFFPI7Hl1JDEb3MP8nabyb5uW61CA3CjueOY433f2k1wijHCVMFnAZV9nGDY1ttThy9qn7TWWQ9XWnkZFnhpLFz
X-IPAS-Result: A2ECAAA9MKVc/zGZrQpiAxkBAQEBAQEBAQEBAQEHAQEBAQEBgVEEAQEBAQELAYEOUwWBEoEqCoQEiByKbYIWJYMKU5RjgT8XJQsBAwEjC4FJgnUCF4VQNAkNAQEDAQEBCAEDAgEBAoEFDII6IhxNLwkBMgEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQgCCAUCNRIBARgBAQEBAwUBHQIIARseIAICAQgRAwECBgEBAQ4BAQgHAwICAgUQAQMLDBQJCAIEAREBBgiCSUsBggStA4EvhUaEWQ8FgSsBi0mBQT6BOAwTgU5+PoJhAQEDgUgtCQEVEQECBYI7MYImA4pJBoI5hCgegWuKGYIuhQNgAwYChwMBeIdfhDWCBV2JD4hWijuBEIVMTo1PAgQCBAUCFYFNgg9wFWUBgkEJgg0XgQEBAoIgKIUUhT9yCQMBJI09AgUIFYEKgR8BAQ
Received: from BRN1WNEX01.vcorp.ad.vrsn.com (10.173.153.48) by BRN1WNEX02.vcorp.ad.vrsn.com (10.173.153.49) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256) id 15.1.1713.5; Wed, 3 Apr 2019 18:20:01 -0400
Received: from BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d]) by BRN1WNEX01.vcorp.ad.vrsn.com ([fe80::a89b:32d6:b967:337d%5]) with mapi id 15.01.1713.004; Wed, 3 Apr 2019 18:20:01 -0400
From: "Gould, James" <jgould@verisign.com>
To: "martin.casanova@switch.ch" <martin.casanova@switch.ch>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] [regext] review of draft-ietf-regext-login-security-03
Thread-Index: AQHU4/1NFoKNCkYc0kavcma5RxCSoaYrDseA
Date: Wed, 03 Apr 2019 22:20:01 +0000
Message-ID: <878793C3-AE5B-4364-AA0A-572467EDB0D6@verisign.com>
References: <afac0d26-e054-54a3-306b-5ec5a49fd489@switch.ch> <7597ff38-29ba-77e3-e093-524c5cb7123a@switch.ch>
In-Reply-To: <7597ff38-29ba-77e3-e093-524c5cb7123a@switch.ch>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.7.190210
x-originating-ip: [10.170.148.18]
Content-Type: multipart/related; boundary="_004_878793C3AE5B4364AA0A572467EDB0D6verisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/RYrz8k68uA9GrQSQ8B5q1zuz_GQ>
Subject: Re: [regext] review of draft-ietf-regext-login-security-03
X-BeenThere: regext@ietf.org
X-Mailman-Version: 2.1.29
Precedence: list
List-Id: Registration Protocols Extensions <regext.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/regext>, <mailto:regext-request@ietf.org?subject=unsubscribe>
List-Archive: <https://mailarchive.ietf.org/arch/browse/regext/>
List-Post: <mailto:regext@ietf.org>
List-Help: <mailto:regext-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/regext>, <mailto:regext-request@ietf.org?subject=subscribe>
X-List-Received-Date: Wed, 03 Apr 2019 22:20:09 -0000

Martin,

Thank you for doing a detailed review of draft-ietf-regext-login-security.  I provide my responses to your feedback embedded below.

—

JG

[cid:image001.png@01D255E2.EB933A30]

James Gould
Distinguished Engineer
jgould@Verisign.com

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

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

From: regext <regext-bounces@ietf.org> on behalf of Martin Casanova <martin.casanova@switch.ch>
Date: Tuesday, March 26, 2019 at 1:56 PM
To: "regext@ietf.org" <regext@ietf.org>
Subject: [EXTERNAL] [regext] review of draft-ietf-regext-login-security-03

Jim

Since we support that draft I started implementing and read it again more carefully. I have the following comments / feedback

1. (comment) Event type "cipher" or "tlsProtocol" :

In case the client uses deprecated protocol or cipher we currently hang up the TLS connection immediately so there is no possibility to send a type "error" security event.
At chapter 3.1 near "exDate" is written that "At expiry there MAY be an error to connect or MAY be an error to login." So in case of an error to connect you run in the same situation and will not be able to send back a "error" level event but thats OK. However it is useful to warn the client during a transition period when we know that we are going to disable a certain cipher or TLS protocol on a specific day in the future.
JG – Yes, connectivity events like “cipher”, “tlsProtocol”, and “certificate” are really only useful when they are provided as a warning with an optional exDate to indicate when the event will result in a connection error.  The policies for the possible set of events can be defined using the Login Security Policy Extension (https://tools.ietf.org/html/draft-gould-regext-login-security-policy), which is an extension of the Registry Mapping (https://tools.ietf.org/html/draft-gould-carney-regext-registry).  The clients need to look for the security events in the login response to act on them.

2 . (comment) Event type “newPw”:
Here we currently use  2306 “Parameter value policy error” and write in the <reason> of <extValue> element that the new password was too weak.
I guess we would use the loginSec Event in the future in case the extension was specified at login whether the pw was changed via login-security extension or not.

I know that you have foreseen draft-gould-regext-login-security-policy to query about password complexity but I think for convenience of the registrar it would still be nice to somehow include the password requirement in the response even if it is redundant. Otherwise one has to implement draft-gould-regext-login-security-policy  at the same time or communicate the requirement out of band.

Maybe like that

   S:        <loginSec:event

   S:          type=”newPW”

   S:          value=”expression: (?=.*\d)(?=.*[a-zA-Z])(?=.*[\x21-\x2F\x3A-\x40\x5B-\x60\x7B-\x7E]) (?!^\s+) (?!.*\s+$)(?!.*\s{2,})^[\x20-\x7e]{16,128}$”

   S:          level=”error”>

   S:          New password does not meet complexity requirements

   S:        </loginSec:event>

   S:    <result code=”2200”>

   S:      <msg>Authentication error</msg>

Are you sure you want to return a 2200 and not a 2306 Parameter value policy error in this case (page 10). I don’t see a reason why this should be another return code with or without extension.

JG – On the first part of your feedback, I’m not sure that we want to inject policy elements into the error response.  Of course the policy information could be embedded within the human readable message, such as below.  I don’t recommend the client parsing the human readable message for policy information, but this would be useful for logging and troubleshooting on the client-side.  One issue is that the client can only receive the password complexity expression upon an error.  It’s best to handle the password complexity expression out-of-band or via the Login Security Policy Extension (draft-gould-regext-login-security-policy) to enable the client to know about the policy prior to an error.

   S:        <loginSec:event

   S:          type=”newPW”

   S:          level=”error”>

   S:          New password does not meet complexity requirement: (?=.*\d)(?=.*[a-zA-Z])(?=.*[\x21-\x2F\x3A-\x40\x5B-\x60\x7B-\x7E]) (?!^\s+) (?!.*\s+$)(?!.*\s{2,})^[\x20-\x7e]{16,128}$

   S:        </loginSec:event>

JG – On the second part of your feedback, I believe that the login should fail if an invalid new password is passed with a 2200 “Authentication error”.  The use of 2200 is not normative, so the server could choose a different result code, such as 2306.  The Login Security Extension will provide more specific information associated with the error.  Are there thoughts from others related to which error result code (2200, 2306, or other) should be used for an invalid new password and whether it should be normative?

3. (question) Event type "stat" :

How often would you send back this event

   <loginSec:event

     type="stat"

     name="failedLogins"

     level="warning"

     value="100"

     duration="P1D">

     Excessive invalid daily logins

   </loginSec:event>

Only once with first successful login after the series of failed ones or for a whole day ? I suggest one time with first successful login.

JG – My thought is that returning the statistical information should not be stateful, so that means that the interval would be up to the server (e.g., for a one day duration start calculating the statistic based on a start / end of midnight UTC), but all applicable events would be returned in all login responses.  I do not recommend the server keeping track of which events have been returned and which have not been returned.  What are your thoughts on this?

4. (question) In chapter 4.1 EPP <login> Command is written

..

internal contiguous

       whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage

       return), and #x20 (space) is replaced with a single #x20 (space).

...

Since this is "normal" XML parsing behavior should there not be reference to where this is described for general XML processing. (I don't know where that would be though)

JG – The choice was to directly include the definition within the draft in place of referencing out.  I’m not aware of an RFC that can be referenced for the XML processing of an XML schema “token” type.  My recommendation is to leave the definition directly in the draft without an external reference.

5.  (suggestion) The element  <loginSec:userAgent> could be more structured to make it easier for the registry to parse the different fields and to give a hint to the registrar what information should be provided.

Therefore I suggest  child elements for example

<os>           Operating System
<client>      Client technology (eg. java)
<version> Client software version (eg. 1.8.0) etc.

JG – If we were going to make the <loginSec:userAgent> structured, my recommendation is to handle it with the following definition:

   <complexType name="userAgentType">

    <sequence>

      <element name="client" type="token"

       minOccurs="0"/>

      <element name="lang" type="token"

       minOccurs="0"/>

      <element name="os" type="token"

       minOccurs="0"/>

    </sequence>

   </complexType>

JG – Below would be an example structured <loginSec:userAgent> element:

   <loginSec:userAgent>

     <loginSec:client>EPP SDK 1.0.0</loginSec:client>

     <loginSec:lang>Java 11.0.2</loginSec:lang>

     <loginSec:os>x86_64 Mac OS X 10.21</loginSec:os>

   </loginSec:userAgent>

JG – What are your thoughts on the structured version of the <loginSec:userAgent> element.  If this works, I will revise the draft to support it.



Thanks



Martin Casanova



--

---

SWITCH

Martin Casanova, Domain Applications

Werdstrasse 2, P.O. Box, 8021 Zurich, Switzerland

phone +41 44 268 15 55, direct +41 44 268 16 25

martin.casanova@switch.ch<mailto:martin.casanova@switch.ch>, www.switch.ch<http://www.switch.ch>



Working for a better digital world