Re: [regext] Roman Danyliw's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)

"Gould, James" <jgould@verisign.com> Wed, 22 January 2020 21:42 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 F3D5512001B; Wed, 22 Jan 2020 13:42:16 -0800 (PST)
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_HELO_NONE=0.001, SPF_PASS=-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 xrq8nmSkPiBU; Wed, 22 Jan 2020 13:42:13 -0800 (PST)
Received: from mail6.verisign.com (mail6.verisign.com [69.58.187.32]) (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 C132512008A; Wed, 22 Jan 2020 13:42:12 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=34773; q=dns/txt; s=VRSN; t=1579729333; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=c+hGwH9aRAyadoKVedH61lHBaFhoACDs1Jnx9rJz6Dg=; b=U4ZuIv/n7Nuqv9KCImg35WsgGvXsDcm0Pea0OBm5GJEXESEs99jJ+BSO avBv21PiEwOzM9iFuaubS1DeViXjPdn8vEVNPRS9IFGFDe7VV2MZVZ6lY JKCQGgn8JCjfDAcc07Bw/n/XmEvkQml5qs0X7DboiRNezIiFgXNY/6P67 7aDbbA1UA9DNpZhb2EACR4zOGc1AxG+OWmClbdrfLh2cnB3wAXJlzpxMX w7JHTkO5RWXgH3czKnc1prXiQISkzgRtZ5iMUUOPMq7DGoP+dhGpBPlV9 xJWAJPJoHIUrGPAaLs7kRQwN6TOtXOQlZRBMXJ5yrJP5eyaWK1sK9aJA7 A==;
IronPort-SDR: 2NyT8BIMr4FCfpTpCbD3AxZKy/btj43YZYulkxIWN8HUUN7lf655glV5FDdwfIryV3Uae/w+HK gisw6jV0VPbfDw0lmi7/AweBO9E/U2ag0l+KetbxM3h4nSThyTd0PWF7ru5PeuAZTfIRqfwrUx bRxzZGDKPtt+NQufgqISviOz3jtD6HPyqq/awnFjTvKFm5ah9SGonbYAOCk87176P5smQ608Ki 0FeVn2YP4DhkV1AOaVJR0OW4KQQBJZqfPPtUjGnKv6CCGqIJVBdRjHRO0WJudgQggIAz/yPMmz rIs=
X-IronPort-AV: E=Sophos;i="5.70,351,1574139600"; d="scan'208,217";a="485823"
IronPort-PHdr: =?us-ascii?q?9a23=3AgaJT3B97Lcp/0/9uRHKM819IXTAuvvDOBiVQ1K?= =?us-ascii?q?B+0eIUIJqq85mqBkHD//Il1AaPAdyHragcwLOK7eigATVGvc/a9ihaMdRlbF?= =?us-ascii?q?wssY0uhQsuAcqIWwXQDcXBSGgEJvlET0Jv5HqhMEJYS47UblzWpWCuv3ZJQk?= =?us-ascii?q?2sfQV6Kf7oFYHMks+5y/69+4HJYwVPmTGxfa5+IA+5oAnMucQam5VuJro+xh?= =?us-ascii?q?fUrXZFevldyWd0KV6OhRrx6dq88ZB5/yhMp/4t8tNLXLnncag/UbFWFiktPX?= =?us-ascii?q?ov5M3suxnDTA+P6WUZX24LjBdGABXL4Q/jUJvpvST0quRy2C+BPc3rVr80Qi?= =?us-ascii?q?it771qSBDzligKMSMy/XzNhcxxiKJbpw+hpwB6zoXJboyZKOZyc6XAdt4BW2?= =?us-ascii?q?FPQtheWDBAAoOkbosAEewBPfpDr4Lgo1cCtAayCRWwCO/qzDJDm3340rAg0+?= =?us-ascii?q?k5EQ/IwhEuH84AvnrXotX6NqkdUeGpw6bH1jjMde9a2TLn5YTUaB0so/eBVq?= =?us-ascii?q?9wf8rLzkkvEhvIgluRp4ziIjOV0vkCv3CG5ORkT+2vjnAoqxp/rjOywcosiI?= =?us-ascii?q?bJhoUIylDA6Cp025g1KsOiSE56et6kEZRQtyeAO4RqRcMiRnhltSAnwbMIvp?= =?us-ascii?q?67eTIFyJUhxxPHdfyIbZKI4hP4VOaQLjd4gnNleLSjiBqo7Uegzej8WtG10F?= =?us-ascii?q?lUsipFnMPAtncX1xzc7MWMV/hz/l+51DqSywzf8PxILEI6mKbBNpIswrA9mo?= =?us-ascii?q?AcvEnHBiP6hVn6gLWLekgm5uSk8fnrb7rlq5OGKoN5iRnyMqowlcG8Heg1Nw?= =?us-ascii?q?0DUHKY9Om4z7Lu+EP0TKtXgfA3l6TWq5TXKMUZq6O8DQJY3IQu5Au5Ajy7yt?= =?us-ascii?q?oXh2MHI0hAeB+fiojpPEzBL+7gAPekhlSsjC9rx/fbPr39GpnNLmbMkLPmfb?= =?us-ascii?q?tl9kNS1BI9wc1f6JxMBb8OIe7/VlHruNzGEhA5NBa0w/79BNpny4wSQ3yPAr?= =?us-ascii?q?WCMKPUq1OH+uUvI+yUaI8UvjbyNeQl6ubzgXMlg1MRYKuk0JUNZHylHvlrLV?= =?us-ascii?q?+VbHXoj9sZFGcFpAs+TOjkiF2YVj5TYm6/X6Az5jE8FYKmCZrMS5uzgLOfxi?= =?us-ascii?q?e7H4ZWZmFJClCKC3vna4KEW/IUZCKIPsBhiiAEVaSmS4I5zxGhqRL1xqF7Ie?= =?us-ascii?q?XK4C0YqYjv1N9v5+3cjRsy7yB7D9yB02GRSGF5hmIISCEt3KBwukF9y0mM0b?= =?us-ascii?q?R2g/BCEtxT/fxJWB8gNZHA1+x6F8zyWgXZc9iUUlapWNumAS0oQtIw3dAOf0?= =?us-ascii?q?h9F8y4jh/d0CqlHbAUl6CSCJww9aLc0HnxJ8Bkx3bdyqYuk0QmQtFONW26hq?= =?us-ascii?q?9y7AnTCJDVk0WXjaqqcr4c3CHV/meZ0WWOpF1YUBJ3UajdX3AeZlXZosri60?= =?us-ascii?q?zYQb+uCLAnMgpbxs6ZMKdKa9vpjVtBRP37ItTRf3qxm3usBRaP3r6MdpTle2?= =?us-ascii?q?oD0yTSFEgIihwc/XacOgg/HCehuHnTDD1wGlLzbUPg6+5+qGm0TkUs1QGFc1?= =?us-ascii?q?Vh16ap+h4SnfGcUe0c3r0atyYutzV5B1e90MzKC9qOvQZhe79cYdxuqGtAgF?= =?us-ascii?q?jesgV7drCpKbFmh0FWJx57s2vl2g9rTIJanp5u5E8qwUJTBJm3mAdAeiiX9Z?= =?us-ascii?q?H9JrORLXP9qkOBcanTjxvx18uS9uNHyv09pk6p9FWrGU0/93lPzdRP0mCd6Z?= =?us-ascii?q?OMBw0XB8GiGn0r/gR38umJKhI24JnZgDg1afG5?=
X-IPAS-Result: =?us-ascii?q?A2HAAACPwShe/zGZrQpiAxsBAQEBAQEBBQEBAREBAQMDA?= =?us-ascii?q?QEBgXuBJViBGIExCoQIlR6VYoErFyUJAQEBAQEBAQEBBwETEAwBAQKEPgIXg?= =?us-ascii?q?ig4EwIDAQELAQEBBAEBAQEBBQMBAQEChiAMgjspAWkvCTkBAQEBAQEBAQEBA?= =?us-ascii?q?QEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAggHNBkHNRIBHwYjCkELEAIBB?= =?us-ascii?q?gIOIAEBCAMHAgICMCUCBAENBYJbSwGBfYENk2ubdoEyhElBhTGBOIgjhA2BQ?= =?us-ascii?q?j6BEScggkw+gmQCAQIBgSwBEgEJLQodCQECBYJBMoIsBI1ZA4J1hVwkiU+OQ?= =?us-ascii?q?nADB4I5hz+JVnmEQIJHeIcSkCaOXodSgRCSJgIEAgQFAhWBaYEKWBEIcBU7K?= =?us-ascii?q?gGCQQlHGA2IDRcVgzuFFIU/dAIIAwEkiwgPFYENgRABAQ?=
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.1779.2; Wed, 22 Jan 2020 16:42:03 -0500
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.1779.002; Wed, 22 Jan 2020 16:42:03 -0500
From: "Gould, James" <jgould@verisign.com>
To: Roman Danyliw <rdd@cert.org>, The IESG <iesg@ietf.org>
CC: "draft-ietf-regext-login-security@ietf.org" <draft-ietf-regext-login-security@ietf.org>, Joseph Yee <jyee@afilias.info>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>, "regext@ietf.org" <regext@ietf.org>
Thread-Topic: [EXTERNAL] Roman Danyliw's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)
Thread-Index: AQHV0UylOZaQRNbV6UydLAub3U1XS6f3NvqA
Date: Wed, 22 Jan 2020 21:42:03 +0000
Message-ID: <5939F80A-808F-45E8-B24A-0F38735A5D94@verisign.com>
References: <157971551947.12241.8926230433846451051.idtracker@ietfa.amsl.com>
In-Reply-To: <157971551947.12241.8926230433846451051.idtracker@ietfa.amsl.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.12.200112
x-originating-ip: [10.170.148.18]
Content-Type: multipart/alternative; boundary="_000_5939F80A808F45E8B24A0F38735A5D94verisigncom_"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/I1XsXZG9judfemXZWpk7HtPt3L8>
Subject: Re: [regext] Roman Danyliw's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)
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, 22 Jan 2020 21:42:17 -0000

Roman,



Thank you for your review and feedback.  I include my comments embedded below.



--



JG







James Gould

Distinguished Engineer

jgould@Verisign.com <applewebdata://13890C55-AAE8-4BF3-A6CE-B4BA42740803/jgould@Verisign.com>



703-948-3271

12061 Bluemont Way

Reston, VA 20190



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



On 1/22/20, 12:52 PM, "Roman Danyliw via Datatracker" <noreply@ietf.org> wrote:



    Roman Danyliw 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:

    ----------------------------------------------------------------------



    ** Section 3.1.  When @type=”stat” and the name of the stat is set in @name,

    how does a client know the semantics of this stat?  Is that negotiated out of

    band?



JG - The possible set of "stat" type security event "name" values can be discovered / negotiated out of band or in band via a separate policy EPP extension, such as draft-gould-regext-login-security-policy.



    ** Section 4.1.  Per  <loginSec:userAgent>, how are the clients supposed to

    generate the app, tech or os strings in a way that the server will understand?

    If this is out of scope, please just say so.



JG - Yes, that is out of scope, but there is a concrete example available in the Verisign EPP SDK, which is referenced in section 7.1 of draft-ietf-regext-login-security.



    ----------------------------------------------------------------------

    COMMENT:

    ----------------------------------------------------------------------



    I support Alissa Cooper’s DISCUSS position.



    ** Section 3.1.  Is a @value required when @type=”cipher” or

    @type=”tlsProtocol”? The examples in Section 4 show the use of @value.  Also,

    what format should be used to express the cipher or tlsProtocol?



JG – There is no normative language that requires the “value” for @type=”cipher” or @type=”tlsProtocol”.  It is reasonable to expect an implementer to populate the “value” attribute based on:

  *   the description of the “cipher” and “tlsProtocol” types with “Identifies…”;
  *   the description of the “value” attribute with “Identifies the value that resulted in the login security event”;
  *   the example EPP response where there is a set of login security events.



JG – The format of the “cipher” or “tlsProtocol” is dependent on the server-side TLS library, where the server would return the “cipher” or “tlsProtocol” value provided by the TLS library upon a successful TLS handshake.  The format is left free-form based on this dependency.



    ** Section 3.1.  Per the description of event@lang, please cite the language

    format as coming from Section 3.4.3[W3C.REC-xmlschema-2-20041028]



JG – Yes, I can add the reference to section 3.3.3[W3C.REC-xmlschema-2-20041028] for the “lang” attribute.  I believe that section 3.3.3 is the correct section.



    ** Section 4.1.  Per the children of <loginSec:userAgent>, would supporting a

    more formal approach also be useful -- using SWID (ISO/IEC 19770-2:2015) or

    COSWID (draft-ietf-sacm-coswid)?



JG – I’ll review SWID and COSWID, but I believe the <loginSec:userAgent> children currently meet the needs.





    ** Section 4.1. Per pw and newPW’s descriptions of “all internal continuous

    whitepaces … is replaced with a single #x20” – is this intentionally precluding

    a password with a double space?



JG – The intention is to describe how the XML schema “token” type is handled.  The XML schema “token” type is used in EPP RFC 5730, which draft-ietf-regext-login-security is extending to remove the 16 character constraint.  There is no intention to implicitly or explicitly change the handling of whitespace from what is defined in EPP RFC5730.





    ** Section 4.1. Per “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].”, if non-ASCII characters are

    supported, how does a client know which approach to take with a given server in

    an interoperable.  RFC8265 is a helpful reference but the current text seems to

    provide no guidance.



JG – This language was added based on a discussion with the Area Director to address a concern raised on the mailing list.  The server policy can be communicated out of band or in band using a policy extension such as draft-gould-regext-login-security-policy.



    ** Section 5.  Please note in the Section 5 introduction that the blob between

    the BEGIN and END tags in Section 5.1 are formally specified by XML Schema.



JG – I can add “XML” prior to each “schema” reference in the introduction of section 5.



    ** Section 8.  Please note that the Security Considerations of RFC5730 apply

    and that this document enhances these security services.



JG – I can add a leading sentence to section 8 stating that, “The Security Considerations of [RFC5730] apply in this document, and this document enhances these considerations.”



    ** Editorial Nits

    -- Section 1.  Typo.  s/pssword/password/



JG – I believe the nit is s/pasword/password/ in section 1, which will be fixed.