Re: [regext] Roman Danyliw's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)
"Gould, James" <jgould@verisign.com> Mon, 27 January 2020 13:12 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 D833D12004E; Mon, 27 Jan 2020 05:12:26 -0800 (PST)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -4.298
X-Spam-Level:
X-Spam-Status: No, score=-4.298 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, URIBL_BLOCKED=0.001] autolearn=unavailable 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 W2Pt3bDxLyXU; Mon, 27 Jan 2020 05:12:23 -0800 (PST)
Received: from mail5.verisign.com (mail5.verisign.com [69.58.187.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 E791612004D; Mon, 27 Jan 2020 05:12:22 -0800 (PST)
DKIM-Signature: v=1; a=rsa-sha256; c=simple/simple; d=verisign.com; l=86490; q=dns/txt; s=VRSN; t=1580130743; h=from:to:cc:date:message-id:references:in-reply-to: mime-version:subject; bh=ea8gKopyaCP+ezI4c71NFWivrOBLnpX2LcjQjGhyvp8=; b=KqfFbFJ+GXViQtRZwB93hzT62qUyCsljK7JRXNEzeAdF0rXGDyxYm90Y lAHldR+v39S7iTugdgkTm+qEAD6JqjIa9pPmlTK+IXFOVD+sL5Lk4F+hW bnevcfTGAf8KWlJR7E25RcAbYznhyd7yhNl5dii9nQ8yQDXSzQk50p0o8 HSmlOyO7uBHOpJYUG9JES8BU7qS1viuwbd+Ehfy/X9F9PaSgvTXFJ72zv ZvvVqPKWxpjw7yQY99cMhq65/ofo353RxSSHcq6Ugv/U6TjXbUfJiSuub PYBfe3RaIs4Ie48u3c2gItVPQwZVJTN2JUX8pBWUIBl+qQET8Sac4r7tl w==;
IronPort-SDR: sfOu7F1DG8LRky183GLA0dLaXJdX95QhlxiZgAwEsqndhGLuvubXux9AX9nQF6vx//F5OwE03u DegUbAcNZ1/JAGkQntwqmo8GjoR/d//21btBoeb010iYj23rUD9/mFm3glT4H2IFQJflWbug7z 30UmefwMQzGzTD8q7gIeRK7WjjTOyQp630f3CT4OC4TQbGWEGDiV5SohNyKYA5mpOfqgUmZJOr I6dWIJxeme9WY7zeuUsB5L4mpLsawm9dKXckP/Jwag5NAOGVBJaVMrNzP1+N1oEQrXa0sohmJT JEw=
X-IronPort-AV: E=Sophos;i="5.70,369,1574139600"; d="png'150?scan'150,208,217,150";a="514705"
IronPort-PHdr: 9a23:0Msolh/WksRKl/9uRHKM819IXTAuvvDOBiVQ1KB+1+gUIJqq85mqBkHD//Il1AaPAdyHrakewLaJ++C4ACpcuM3H6ChDOLV3FDY9wf0MmAIhBMPXQWbaF9XNKxIAIcJZSVV+9Gu6O0UGUOz3ZlnVv2HgpWVKQka3OgV6PPn6FZDPhMqrye+y54fTYwJVjzahfL9+Nhq7oRjeu8UMj4ZuNKk9xxTLr3BVf+ha2X5kKUickhrh6Mq85oJv/zhVt/k868NOTKL2crgiQ7dFFjomKWc15MPqtRnHUwSC42YXX3sVnBRVHQXL9Qn2UZjtvCT0sOp9wzSaMtbtTb8oQzSi7rxkRwHuhSwaKjM26mDXish3jKJGvBKsogF0zoDIbI2JMvd1Y7jQds0GS2VfQslRVjRBAoKiYIsJE+oBJvtTo43kq1cTsReyGQygCeXywTFKm3D2x7U33eQ/Hw/bwAwuEdEAsHrWo9r7NacdTe+6wbLSzTnfavNbwyvx5ZLKfx0nvPqCXahwcc3UyUQ3GQ/Lj1KQqZHhPzyIzugGrmyV4PBlVe2xkG4rpRx6rz+txscjjYnJm4YVxU3f+CVn3ok1P9y4SFV6Yd6rFptcrT2VN4xzQs47RWxjpSg0yroDuZGhfSgKzowqxwDBZPydcoiI+RPjVOmXITd5gnJqZKiziAq18Uil0uH8V9e70EpEriZfldnMrH8N2hrO4caEUvtw5lqt1SqV2wzO6OxJL1o4mbfbJpMv2LI9mZ4evVzeEiPqgkn6ka2belk+9uS15OnqYa/qqoKfOoNshAHxLKcjltC6DOk9KAcDXGyW9v+52bDt40H2XbRHg/gtnaTdsZ3XJ8EWq6C3DgJXz4ku7Qu0AS2839QCh3YHKUpIeBeAj4f0JV7DOOv4DfKjg1S0lzdr2uzGMqXhAprTKnjDl6/scKth5UBE1QY8zchR6Z1VBb0dPv7/QFHxu8DfDh8jKwy42fzoB8hn2oMAQ2KPGamZPLnOvl+P4+IjO+iMZIkLtzbhM/Up+uLigWUklVIfc6Slx4YbZXC2E/h8LEiUZWLggtIbHmcLugo+QvbqiFqHUTNLZXayUKU85iw/CI27ForDWJ6igKaA3CegH51WaWZGBkqQHnfvcoWIQ+0MZz6KIs99jjwEUqCsS5U82h6zrwL116RoLvDI+iECspLjztd17fXJlR4u7Tx0E9id02aVQmF2kWMIQCI23KRirkFlxVqPzbZ4jOJCFdxS/PNJUwg6NZjGw+NmDNDyXxnMccqMSFm8WNWpHSs9TtMvzN8SbUZxAdKijgrM3yCyGb8ai6SLBIAo8qLbx3XxJthyy23J1KQ6jlkpXNdPNWO8iq547QjTCJbDk1+FmKayaaQcwCnN+X+ewmqUpk5YXhJwXbzEXX8BekvWo8315lncQL+hF7smPRdBxdeGKqtNZd3pjFNGSO74ONvAf22xhn2wBReUxrKMd4fqensS3DnTCEQelAAT53mGPxAkBii9u2LeECBuFVX3bkPu8ehxtm20Q1QuwAGEbk1h07u19QQOhfCGSvMT2LwEuCA5oTVuAFm9x87WC8aHpwd5ZqVTf9w970lI1GLFrAF9P4KvL7xshlIEdAR3pUzu3Q1tCopcicgqsG8qzA1qJKKCzlxBeC2X3J/sOrHONmby/Aqga6/M2lHFy9uW+7kA6Og2q1n5uwGpDEUioD1b1Ixv1H6V4N3mBQwDVZPuGhIt+xRSrLzAfm86/YyCkTUmHq6ptjOGk/AgAeY+gF70fdhYLaeIQVOqDcAABtOvJ+pskF+sRh4BNfpZsq85I83gcOGJjurjAOZt1BOLtksPtIFwyU2k9idgRKjPxZlTkN+C2Q7SHRj7kVOt9ojVkIVJfntaSmiwzjXgCKZPa7dzZocEDyGlJMjhlYY2vILkR3MNrA3rPFgBwsL8PEPKN1E=
X-IPAS-Result: A2FKAACW4C5e/zGZrQpjAxoBAQEBAQEBAQEDAQEBAREBAQECAgEBAQGBe4ElWIEYgTEKhAqRO4MPX5VjgSsXJQIHAQEBAQEBAQEBAwEDASMMAQECgUqCdAIXgjI4EwIDAQELAQEBBAEBAQEBBQMBAQEChiAMgjspAWkvCTkBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEBAQEFAggHNBkHNRIBAR0BAQEBAwUBFAkCCAFACxACAQYCDgMBAgEBAQYBAQEOAQEIAQIEAwICAgUQDwwUAwYIAgQBDQQBDoJNSwGDCo8XmwJ1gTKENQETQYUqEIE4gwqEIIEBhA2BQj6BEScggkw+gmQCAQEBAYEsARIBCRAdCQEVCAkBAgWCQTKCLASNSg4BAzKCQ4VeJG6IY4Upgm2GLnADB4I5hiACgSCJV3mEQIJIeIcShEWLZY0mgTqHVIEQkikCBAIEBQIVgWmBClgRCHAVOyoBgkEJRxgNk3gXFW8BCIJDhRSFP3QCCAMBJIsPDxWBDYEQAQE
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; Mon, 27 Jan 2020 08:12:17 -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; Mon, 27 Jan 2020 08:12:17 -0500
From: "Gould, James" <jgould@verisign.com>
To: Roman Danyliw <rdd@cert.org>, "Gould, James" <jgould=40verisign.com@dmarc.ietf.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@ietf.org" <regext@ietf.org>, "regext-chairs@ietf.org" <regext-chairs@ietf.org>
Thread-Topic: [EXTERNAL] RE: Roman Danyliw's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT)
Thread-Index: AQHV0wqbw+rtdUCmEkCObjnYZI3z/qf+gLoA
Date: Mon, 27 Jan 2020 13:12:17 +0000
Message-ID: <37FFA099-4DAC-4C16-B869-20534615DF3B@verisign.com>
References: <0790CB25-3ADD-48E3-97D5-FD11A1F95A90@verisign.com>
In-Reply-To: <0790CB25-3ADD-48E3-97D5-FD11A1F95A90@verisign.com>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach: yes
X-MS-TNEF-Correlator:
user-agent: Microsoft-MacOutlook/10.10.12.200112
x-originating-ip: [10.170.148.18]
Content-Type: multipart/related; boundary="_005_37FFA0994DAC4C16B86920534615DF3Bverisigncom_"; type="multipart/alternative"
MIME-Version: 1.0
Archived-At: <https://mailarchive.ietf.org/arch/msg/regext/laLez-VYxiKL4GAq4ze5weKz2Fg>
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: Mon, 27 Jan 2020 13:12:27 -0000
Roman, In thinking about a little bit more, I believe the ABNF for the <loginSec:app> element value needs to be simplified and made more consistent with the other ABNF with: app = name SP version name = 1*VCHAR version = 1*VCHAR Does the use of the ABNF help to clarify how to create the <loginSec:userAgent> child element values? Thanks, -- JG [cid:image001.png@01D255E2.EB933A30] 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/> From: James Gould <jgould@verisign.com> Date: Friday, January 24, 2020 at 6:04 PM To: Roman Danyliw <rdd@cert.org>, "Gould, James" <jgould=40verisign.com@dmarc.ietf.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@ietf.org" <regext@ietf.org>, "regext-chairs@ietf.org" <regext-chairs@ietf.org> Subject: Re: [EXTERNAL] RE: Roman Danyliw's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT) Roman, I provide proposed updates below with the JG2 prefix. -- JG [cid:image001.png@01D255E2.EB933A30] 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/> From: Roman Danyliw <rdd@cert.org> Date: Thursday, January 23, 2020 at 8:36 AM To: "Gould, James" <jgould=40verisign.com@dmarc.ietf.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@ietf.org" <regext@ietf.org>, "regext-chairs@ietf.org" <regext-chairs@ietf.org> Subject: [EXTERNAL] RE: Roman Danyliw's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT) Resent-From: <alias-bounces@ietf.org> Resent-To: James Gould <jgould@verisign.com>, <mpozun@verisign.com> Resent-Date: Thursday, January 23, 2020 at 8:36 AM Hi JG! Thanks for the quick response. See details inline … From: iesg <iesg-bounces@ietf.org> On Behalf Of Gould, James Sent: Wednesday, January 22, 2020 4:42 PM To: Roman Danyliw <rdd@cert.org>; The IESG <iesg@ietf.org> Cc: draft-ietf-regext-login-security@ietf.org; Joseph Yee <jyee@afilias.info>; regext@ietf.org; regext-chairs@ietf.org Subject: Re: Roman Danyliw's Discuss on draft-ietf-regext-login-security-07: (with DISCUSS and COMMENT) Roman, Thank you for your review and feedback. I include my comments embedded below. -- JG James Gould Distinguished Engineer jgould@Verisign.com<mailto: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<mailto: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. [Roman] Understood. Can you include a sentence to that effect. JG2 – I believe the best way to handle this is to add the following to the description of the “name” attribute, which will cover both the use of the “name” attribute for the “stat” and “custom” types: The possible set of "name" values, by event type, can be discovered / negotiated out of band to EPP or using a separate EPP extension designed to provide server policy information to the client. ** 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. [Roman] Understood. Can you add a sentence to that effect here too. These would address my concerns. JG2 – To address your, Alexey’s, and Benjamin’s concern, I will add the following bolded text to the draft: <loginSec:app>: OPTIONAL name of the client application software with version if available, such as the name of the client SDK "EPP SDK 1.0.0". The <loginSec:app> element value can be created by appending the version number to the name of the application software, such as the Augmented Backus-Naur Form (ABNF) grammar [RFC5234] format: app = name SP version name = 1*ALPHA *(ALPHA / SP) 1*ALPHA version = 1*DIGIT "." 1*DIGIT "." 1*DIGIT <loginSec:tech>: OPTIONAL technology used for the client software with version if available, such as "Vendor Java 11.0.2". The <loginSec:tech> element value can be created by including the technology vendor, technology name, and technology version, such as the Augmented Backus-Naur Form (ABNF) grammar [RFC5234] format: tech = vendor SP name SP version vendor = 1*VCHAR name = 1*VCHAR version = 1*VCHAR <loginSec:os>: OPTIONAL client operating system used with version if available, such as "x86_64 Mac OS X 10.14.6". The <loginSec:os> element value can be created by including the operating system architecture, operating system name, and operating system version, such as the Augmented Backus-Naur Form (ABNF) grammar [RFC5234] format: os = arch SP name SP version arch = 1*VCHAR name = 1*VCHAR version = 1*VCHAR JG2 – Is this what you were looking for? ---------------------------------------------------------------------- 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. [Roman] No problem. Thanks for the clarification. ** 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. [Roman] Thanks. ** 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. [Roman] No problem. I wanted to ensure there was awareness of related work on an XML approach to what seemed like the same approach. ** 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. [Roman] I understand the thinking – just read it as a token type (which it would be anyway per the schema). Thanks for clarifying. ** 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. [Roman] Understood. IMO, noting that this kind of policy should/could be communicated out of band would be a helpful clarification. ** 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. [Roman] Thanks. This is really a reference nit – if you use a formal language, just cite it. ** 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.” [Roman] Thanks. Works for me. ** Editorial Nits -- Section 1. Typo. s/pssword/password/ JG – I believe the nit is s/pasword/password/ in section 1, which will be fixed. [Roman] Right – with some irony, that’s the typo I was referencing with my own typo. Thanks. Thanks, Roman
- [regext] Roman Danyliw's Discuss on draft-ietf-re… Roman Danyliw via Datatracker
- Re: [regext] Roman Danyliw's Discuss on draft-iet… Gould, James
- Re: [regext] Roman Danyliw's Discuss on draft-iet… Roman Danyliw
- Re: [regext] Roman Danyliw's Discuss on draft-iet… Gould, James
- Re: [regext] Roman Danyliw's Discuss on draft-iet… Gould, James
- Re: [regext] Roman Danyliw's Discuss on draft-iet… Alexey Melnikov