--- 1/draft-ietf-regext-login-security-05.txt 2019-11-18 15:13:11.584874904 -0800 +++ 2/draft-ietf-regext-login-security-06.txt 2019-11-18 15:13:11.624875928 -0800 @@ -1,18 +1,18 @@ Network Working Group J. Gould Internet-Draft M. Pozun Intended status: Standards Track VeriSign, Inc. -Expires: May 1, 2020 October 29, 2019 +Expires: May 22, 2020 November 19, 2019 Login Security Extension for the Extensible Provisioning Protocol (EPP) - draft-ietf-regext-login-security-05 + draft-ietf-regext-login-security-06 Abstract The Extensible Provisioning Protocol (EPP) includes a client authentication scheme that is based on a user identifier and password. The structure of the password field is defined by an XML Schema data type that specifies minimum and maximum password length values, but there are no other provisions for password management other than changing the password. This document describes an EPP extension that allows longer passwords to be created and adds @@ -26,21 +26,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on May 1, 2020. + This Internet-Draft will expire on May 22, 2020. Copyright Notice Copyright (c) 2019 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -77,30 +77,31 @@ Appendix A. Change History . . . . . . . . . . . . . . . . . . . 20 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 20 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 20 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 20 A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 20 A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 20 A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 21 A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 21 A.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 22 A.9. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 22 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 22 + A.10. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 22 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 1. Introduction This document describes an Extensible Provisioning Protocol (EPP) extension for enhancing the security of the EPP login command in EPP - RFC 5730. The enhancements include supporting longer passwords (or + [RFC5730]. The enhancements include supporting longer passwords (or passphrases) than the 16-character maximum and providing a list of security events in the login response. The password (current and - new) in EPP RFC 5730 can be overridden by the password included in + new) in EPP [RFC5730] can be overridden by the password included in the extension to extend past the 16-character maximum. The security events supported include: password expiry, client certificate expiry, insecure cipher, insecure TLS protocol, new pasword complexity, login security statistical warning, and a custom event. The attributes supported by the security events include identifying the event type or sub-type, indicating the security level of warning or error, a future or past-due expiration date, the value that resulted in the event, the duration of the statistical event, and a free-form description with an optional language. @@ -127,24 +128,24 @@ "loginSec" is used, but implementations MUST NOT depend on it and instead employ a proper namespace-aware XML parser and serializer to interpret and output the XML documents. 2. Migrating to Newer Versions of This Extension Servers which implement this extension SHOULD provide a way for clients to progressively update their implementations when a new version of the extension is deployed. - Servers SHOULD (for a temporary migration period) provide support for - older versions of the extension in parallel to the newest version, - and allow clients to select their preferred version via the - element of the command. + Servers SHOULD (for a temporary migration period up to server policy) + provide support for older versions of the extension in parallel to + the newest version, and allow clients to select their preferred + version via the element of the command. If a client requests multiple versions of the extension at login, then, when preparing responses to commands which do not include extension elements, the server SHOULD only include extension elements in the namespace of the newest version of the extension requested by the client. When preparing responses to commands which do include extension elements, the server SHOULD only include extension elements for the extension versions present in the command. @@ -969,21 +968,31 @@ "en" (English). 8. In section 3.1, change example description from "Example login security event for a password expiring in a week:" to "Example login security event for password expiration, where the current date is 2018-03-25:". 9. In section 4.1, change "Example EPP response to a successful login command where the password will expire in a week:" to "Example EPP response to a successful login command on 2018-03-25, where the password will expire in a week:". +A.10. Change from REGEXT 05 to REGEXT 06 + + Updates based on the review by Brian Carpenter, that include: + + 1. In section 1, change the references to RFC 5730 to use links. + + 2. In section 2, change "(for a temporary migration period)" to + "(for a temporary migration period up to server policy)". + Authors' Addresses + James Gould VeriSign, Inc. 12061 Bluemont Way Reston, VA 20190 US Email: jgould@verisign.com URI: http://www.verisign.com Matthew Pozun