Diff: rfc8807xml2.original.xml

	rfc8807xml2.original.xml	rfc8807.xml

	<?xml version="1.0" encoding="US-ASCII"?>	<?xml version="1.0" encoding="UTF-8"?>
	<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [	<!DOCTYPE rfc SYSTEM "rfc2629-xhtml.ent">
	<!-- One method to get references from the online citation libraries.
	There has to be one entity for each item to be referenced.	<rfc xmlns:xi="http://www.w3.org/2001/XInclude" submissionType="IETF"
	An alternate method (rfc include) is described in the references. -->	category="std" consensus="true"
	<!ENTITY RFC2119 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC	docName="draft-ietf-regext-login-security-10" number="8807"
	.2119.xml">	ipr="trust200902" obsoletes="" updates="" xml:lang="en" tocInclude="true"
	<!ENTITY RFC3688 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC	tocDepth="4" symRefs="true" sortRefs="true" version="3">
	.3688.xml">
	<!ENTITY RFC5234 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC	<!-- xml2rfc v2v3 conversion 2.40.1 -->
	.5234.xml">
	<!ENTITY RFC5730 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.5730.xml">
	<!ENTITY RFC7451 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7451.xml">
	<!ENTITY RFC7942 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.7942.xml">
	<!ENTITY RFC8174 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8174.xml">
	<!ENTITY RFC8265 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC
	.8265.xml">
	<!ENTITY W3C.REC-xmlschema-2-20041028 PUBLIC '' 'http://xml2rfc.ietf.org/public/
	rfc/bibxml4/reference.W3C.REC-xmlschema-2-20041028.xml'>]>
	<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
	<!-- used by XSLT processors -->
	<!-- For a complete list and description of processing instructions (PIs),
	please see http://xml.resource.org/authoring/README.html. -->
	<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds
	might want to use.
	(Here they are set differently than their defaults in xml2rfc v1.32) -->
	<?rfc strict="yes" ?>
	<!-- give errors regarding ID-nits and DTD validation -->
	<!-- control the table of contents (ToC) -->
	<?rfc toc="yes"?>
	<!-- generate a ToC -->
	<?rfc tocdepth="4"?>
	<!-- the number of levels of subsections in ToC. default: 3 -->
	<!-- control references -->
	<?rfc symrefs="yes"?>
	<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
	<?rfc sortrefs="yes" ?>
	<!-- sort the reference entries alphabetically -->
	<!-- control vertical white space
	(using these PIs as follows is recommended by the RFC Editor) -->
	<?rfc compact="yes" ?>
	<!-- do not start each main section on a new page -->
	<?rfc subcompact="yes"?>
	<!-- keep one blank line between list items -->
	<?rfc comments="yes" ?>
	<!-- show cref output -->
	<?rfc inline="yes" ?>
	<!-- inline cref output -->
	<!-- end of list of popular I-D processing instructions -->
	<rfc category="std" docName="draft-ietf-regext-login-security-10" ipr="trust2009
	02">
	<!-- category values: std, bcp, info, exp, and historic
	ipr values: full3667, noModification3667, noDerivatives3667
	you can add the attributes updates="NNNN" and obsoletes="NNNN"
	they will automatically be output with "(if approved)" -->

	<!-- *** FRONT MATTER *** -->	<!-- *** FRONT MATTER *** -->

	<front>	<front>

	<title abbrev="loginSec">	<title abbrev="Login Security Extension for the EPP">
	Login Security Extension for the Extensible Provisioning Protocol (EPP)</tit le>	Login Security Extension for the Extensible Provisioning Protocol (EPP)</tit le>

		<seriesInfo name="RFC" value="8807"/>
	<author fullname="James Gould" initials="J.G" surname="Gould">	<author fullname="James Gould" initials="J." surname="Gould">
	<organization>VeriSign, Inc.</organization>	<organization>VeriSign, Inc.</organization>


	<address>	<address>
	<postal>	<postal>
	<street>12061 Bluemont Way</street>	<street>12061 Bluemont Way</street>


	<city>Reston</city>	<city>Reston</city>


	<region>VA</region>	<region>VA</region>


	<code>20190</code>	<code>20190</code>

		<country>United States of America</country>
	<country>US</country>
	</postal>	</postal>


	<email>jgould@verisign.com</email>	<email>jgould@verisign.com</email>


	<uri>http://www.verisign.com</uri>	<uri>http://www.verisign.com</uri>
	</address>	</address>
	</author>	</author>

		<author fullname="Matthew Pozun" initials="M." surname="Pozun">
	<author fullname="Matthew Pozun" initials="M.P" surname="Pozun">
	<organization>VeriSign, Inc.</organization>	<organization>VeriSign, Inc.</organization>


	<address>	<address>
	<postal>	<postal>
	<street>12061 Bluemont Way</street>	<street>12061 Bluemont Way</street>


	<city>Reston</city>	<city>Reston</city>


	<region>VA</region>	<region>VA</region>


	<code>20190</code>	<code>20190</code>

		<country>United States of America</country>
	<country>US</country>
	</postal>	</postal>


	<email>mpozun@verisign.com</email>	<email>mpozun@verisign.com</email>


	<uri>http://www.verisign.com</uri>	<uri>http://www.verisign.com</uri>
	</address>	</address>
	</author>	</author>

		<date month="August" year="2020"/>
	<date day="26" month="February" year="2020"/>

	<abstract>	<abstract>

	<t>The Extensible Provisioning Protocol (EPP) includes a client authentica	<t>The Extensible Provisioning Protocol (EPP) includes a client
	tion scheme	authentication scheme that is based on a user identifier and
	that is based on a user identifier and password. The structure of the pass	password. The structure of the password field is defined by an XML
	word field is defined	Schema data type that specifies minimum and maximum password length
	by an XML Schema data type that specifies minimum and maximum password len	values, but there are no other provisions for password management other
	gth values,	than changing the password.
	but there are no other provisions for password management other than chang
	ing the password.
	This document describes an EPP extension	This document describes an EPP extension

	that allows longer passwords to be created and adds additional security fe	that allows longer passwords to be created and adds additional security
	atures	features to the EPP login command and response.</t>
	to the EPP login command and response.</t>
	</abstract>	</abstract>


	</front>	</front>


	<middle>	<middle>

	<section title="Introduction">	<section numbered="true" toc="default">
		<name>Introduction</name>
	<t>This document describes an Extensible Provisioning Protocol (EPP)	<t>This document describes an Extensible Provisioning Protocol (EPP)

	extension for enhancing the security of the EPP login command in EPP <xref	extension for enhancing the security of the EPP login command in EPP
	target="RFC5730"/>.	<xref target="RFC5730" format="default"/>. EPP <xref target="RFC5730"
	EPP <xref target="RFC5730"/> includes a maximum password length of 16 char	format="default"/> includes a maximum password length of 16 characters,
	acters that inhibits	which inhibits implementing stronger password security policies with
	implementing stronger password security policies with higher entropy.	higher entropy. The enhancements include supporting longer passwords (or
	The enhancements include supporting longer passwords (or passphrases) than	passphrases) than the 16-character maximum and providing a list of
	the 16-character	security events in the login response. The password (current and new)
	maximum and providing a list of security events in the	in EPP <xref target="RFC5730" format="default"/> can be overridden by
	login response. The password (current and new) in EPP <xref target="RFC57	the password included in the extension to extend past the 16-character
	30"/> can be	maximum. The security events supported include password expiry, client
	overridden by the password included in the extension to extend past the 16	certificate expiry, insecure cipher, insecure TLS protocol, new password
	-character maximum.	complexity, login security statistical warning, and a custom event. The
	The security events supported include:	attributes supported by the security events include an identified event
	password expiry, client certificate expiry, insecure cipher, insecure	type or a subtype, an indicated security level of
	TLS protocol, new password complexity, login security statistical warning,	warning or error, a future or past-due expiration date, the
	and a custom event. The attributes supported	value that resulted in the event, the duration of the statistical event,
	by the security events include identifying the event type or sub-type, ind
	icating
	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 statistica
	l event,
	and a free-form description with an optional language.</t>	and a free-form description with an optional language.</t>

		<section numbered="true" toc="default">
	<section title="Conventions Used in This Document">	<name>Conventions Used in This Document</name>
	<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL	<t>
	NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED",	The key words "<bcp14>MUST</bcp14>", "<bcp14>MUST NOT</bcp14>",
	"MAY", and "OPTIONAL" in this document are to be interpreted as	"<bcp14>REQUIRED</bcp14>", "<bcp14>SHALL</bcp14>", "<bcp14>SHALL
	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>	NOT</bcp14>", "<bcp14>SHOULD</bcp14>", "<bcp14>SHOULD NOT</bcp14>",
	when, and only when, they	"<bcp14>RECOMMENDED</bcp14>", "<bcp14>NOT RECOMMENDED</bcp14>",
	appear in all capitals, as shown here.</t>	"<bcp14>MAY</bcp14>", and "<bcp14>OPTIONAL</bcp14>" in this document are
		to be interpreted as
	<t>XML is case sensitive. Unless stated otherwise, XML specifications	described in BCP 14 <xref target="RFC2119"/> <xref target="RFC8174"/>
	and examples provided in this document MUST be interpreted in the	when, and only when, they appear in all capitals, as shown here.
	character case presented in order to develop a conforming
	implementation.</t>

	<t>In examples, "C:" represents lines sent by a protocol client and "S:"
	represents lines returned by a protocol server.
	Indentation and white space in examples are provided only to illustrate
	element relationships
	and are not a required feature of this protocol.
	</t>	</t>

		<t>XML is case sensitive. Unless stated otherwise, XML specifications
		and examples provided in this document <bcp14>MUST</bcp14> be
		interpreted in the character case presented in order to develop a
		conforming implementation.</t>
		<t>In examples, "C:" represents lines sent by a protocol client and
		"S:" represents lines returned by a protocol server. In
		examples, indentation and
		whitespace are provided only to illustrate element
		relationships and are not a required feature of this protocol.</t>
	<t>"loginSec-1.0" is used as an abbreviation for	<t>"loginSec-1.0" is used as an abbreviation for
	"urn:ietf:params:xml:ns:epp:loginSec-1.0". The XML namespace prefix	"urn:ietf:params:xml:ns:epp:loginSec-1.0". The XML namespace prefix

	"loginSec" is used, but implementations MUST NOT depend on	"loginSec" is used, but implementations <bcp14>MUST NOT</bcp14> depend o
	it and instead employ	n
		it. Instead, they are to employ
	a proper namespace-aware XML parser and serializer to interpret and	a proper namespace-aware XML parser and serializer to interpret and
	output the XML documents.</t>	output the XML documents.</t>

		<t>"whitespace" is defined by the XML Schema whiteSpace data type in
	<t>"whitespace" is defined by the XML schema whiteSpace datatype in <xre	<xref target="W3C.REC-xmlschema-2-20041028" format="default"/>, which
	f target="W3C.REC-xmlschema-2-20041028"/>,	only includes the ASCII whitespace characters #x9 (tab), #xA
	which only includes the ASCII whitespace characters #x9 (tab), #xA (line	(linefeed), #xD (carriage return), and #x20 (space).</t>
	feed), #xD (carriage return), and #x20 (space).</t>
	</section>	</section>
	</section>	</section>

		<section numbered="true" toc="default">
	<section title="Migrating to Newer Versions of This Extension">	<name>Migrating to Newer Versions of This Extension</name>
		<t>Servers that implement this extension <bcp14>SHOULD</bcp14> provide a w
	<t>Servers which implement this extension SHOULD provide a way for	ay for
	clients to progressively update their implementations when a new	clients to progressively update their implementations when a new
	version of the extension is deployed. A newer version of the extension	version of the extension is deployed. A newer version of the extension

	is expected to use an XML namespace with a higher version number than t	is expected to use an XML namespace with a higher version number than
	he prior versions.</t>	the prior versions.</t>
		<t>Servers <bcp14>SHOULD</bcp14> (for a temporary migration period up to
	<t>Servers SHOULD (for a temporary migration period up to server policy)	server policy) provide support for
	provide support for	older versions of the extension in parallel to the newest version
	older versions of the extension in parallel to the newest version,
	and allow clients to select their preferred version via the	and allow clients to select their preferred version via the
	<svcExtension> element of the <login> command.</t>	<svcExtension> element of the <login> command.</t>

		<t>If a client requests multiple versions of the extension at login,
	<t>If a client requests multiple versions of the extension at log	then, when preparing responses to commands that do not include
	in,	extension elements, the server <bcp14>SHOULD</bcp14> only include ext
	then, when preparing responses to commands which do not include	ension elements
	extension elements, the server SHOULD only include extension elements
	in the namespace of the newest version of the extension requested by	in the namespace of the newest version of the extension requested by
	the client.</t>	the client.</t>

		<t>When preparing responses to commands that do include extension
	<t>When preparing responses to commands which do include extension	elements, the server <bcp14>SHOULD</bcp14> only include extension ele
	elements, the server SHOULD only include extension elements for the	ments for the
	extension versions present in the command.</t>	extension versions present in the command.</t>


	</section>	</section>

		<section anchor="attrs" numbered="true" toc="default">
	<section anchor="attrs" title="Object Attributes">	<name>Object Attributes</name>
		<t>This extension adds additional elements to <xref target="RFC5730"
	<t>This extension adds additional elements to <xref target="RFC5730"/> log	format="default"/> login command and response. Only those new elements
	in command
	and response. Only those new elements
	are described here.</t>	are described here.</t>

		<section anchor="event" numbered="true" toc="default">
	<section anchor="event" title="Event">	<name>Event</name>
		<t>A security event using the <loginSec:event> element
	<t>A security event, using the <loginSec:event> element,
	represents either a warning or error identified by the server after	represents either a warning or error identified by the server after

	the client has connected and submitted the login command. The <loginS	the client has connected and submitted the login command. The
	ec:event> element	<loginSec:event> element is contained in a list of one or more
	is contained in a list of one or more elements in the <loginSec:login	elements in the <loginSec:loginSecData> element, so there
	SecData> element,	<bcp14>MAY</bcp14> be multiple events returned that provide
	so there MAY be multiple events returned that provide information for th	information for the client to address. The <loginSec:event>
	e client to address.	<bcp14>MAY</bcp14> include a free-form description. All of the
	The <loginSec:event> MAY include a free-form description.	security events use a consistent set of attributes, where the exact
	All of the security events use a consistent set of attributes,	set of applicable attributes is based on the event type. The supported
	where the exact set of applicable attributes is based on the event type.	set of <loginSec:event> element attributes include:</t>
	The supported set of <loginSec:event> element attributes include:<	<dl newline="false" indent="4">
	/t>	<dt>"type":</dt>
		<dd>A <bcp14>REQUIRED</bcp14> attribute that defines the type of
	<t><list hangIndent="4" style="hanging">	security event. The enumerated list of "type" values includes:</dd>
	<t hangText=""type":">A REQUIRED attribute that	<dt/>
	defines the type of security event. The enumerated list of "type" va	<dd>
	lues includes:</t>	<dl newline="false" indent="4">
		<dt>"password":</dt>
	<t><list hangIndent="4" style="hanging">	<dd>Identifies a password expiry event where the password
	<t hangText=""password":">Identifies a	expires in the future or has expired based on the "exDate" date
	password expiry event, where the password expires in the future or has expired b	and time. The "exDate" attribute <bcp14>MUST</bcp14> be set with
	ased on the "exDate" date and time.	the password expiry date and time.</dd>
	The "exDate" attribute MUST be set with the password expiry date and tim	<dt>"certificate":</dt>
	e.</t>	<dd>Identifies a client certificate expiry event where the
	<t hangText=""certificate":">Identifies	client certificate will expire at the "exDate" date and
	a client certificate expiry event, where the client certificate will expire at	time. The "exDate" attribute <bcp14>MUST</bcp14> be set with the
	the "exDate" date and time.	certificate expiry date and time.</dd>
	The "exDate" attribute MUST be set with the certificate expiry date and	<dt>"cipher":</dt>
	time.</t>	<dd>Identifies the use of an insecure or deprecated TLS cipher
	<t hangText=""cipher":">Identifies the	suite. The "name" attribute <bcp14>MUST</bcp14> be set with the
	use of an insecure or deprecated TLS cipher suite.	name of the cipher suite, which is free-form and is not expected
	The "name" attribute MUST be set with the name of the cipher suite, wh	to be parsed and automatically addressed by the client. An
	ich is free-form and is not	example of cipher suite names can be found in the TLS Cipher
	expected to be parsed and automatically addressed by the client.	Suites of the <eref
	An example of cipher suite names can be found in the TLS Cipher Suites	target="https://www.iana.org/assignments/tls-parameters/tls-paramet
	of the	ers.xhtml#tls-parameters-4">"Transport
	<eref target="https://www.iana.org/assignments/tls-parameters/tls-para	Layer Security (TLS) Parameters" registry</eref>.</dd>
	meters.xhtml#tls-parameters-4">Transport Layer Security (TLS) Parameters IANA Re	<dt>"tlsProtocol":</dt>
	gistry</eref>.	<dd>Identifies the use of an insecure or deprecated TLS
	</t>	protocol. The "name" attribute <bcp14>MUST</bcp14> be set with
	<t hangText=""tlsProtocol":">Identifies	the name of the TLS protocol, which is free-form and is not
	the use of an insecure or deprecated TLS protocol.	expected to be parsed and automatically addressed by the
	The "name" attribute MUST be set with the name of the TLS protocol,	client.</dd>
	which is free-form and is not expected to be parsed and automatically	<dt>"newPW":</dt>
	addressed by the client.</t>	<dd>The new password does not meet the server password
	<t hangText=""newPW":">The new password	complexity requirements.</dd>
	does not meet the server password complexity requirements.</t>	<dt>"stat":</dt>
	<t hangText=""stat":">Provides a login	<dd>Provides a login security statistical warning that
	security statistical warning that MUST set the "name" attribute to the name of t	<bcp14>MUST</bcp14> set the "name" attribute to the name of the
	he statistic sub-type.</t>	statistic subtype.</dd>
	<t hangText=""custom":">Custom event ty	<dt>"custom":</dt>
	pe that MUST set the "name" attribute with the custom event type name.</t>	<dd>Custom event type that <bcp14>MUST</bcp14> set the "name"
	</list></t>	attribute with the custom event type name.</dd>
		</dl>
	<t hangText=""name":">Used to define a sub-type	</dd>
	when the "type" attribute is not "custom" or the full type name when the "type"	<dt>"name":</dt>
	attribute is "custom". The	<dd>Used to define a subtype when the "type" attribute is not
	"name" attribute MUST be set when the "type" attribute i	"custom" or the full type name when the "type" attribute is
	s "stat" or "custom".	"custom". The "name" attribute <bcp14>MUST</bcp14> be set when the
	The possible set of "name" values, by event type, can be discovered / neg	"type" attribute is "stat" or "custom". The possible set of "name"
	otiated out of band to EPP or	values, by event type, can be discovered/negotiated out of band to
	using a separate EPP extension designed to provide server policy informat	EPP or using a separate EPP extension designed to provide server
	ion to the client.</t>	policy information to the client.</dd>
	<t hangText=""level":">Defines the level of the	<dt>"level":</dt>
	event as either "warning" for a warning event	<dd>Defines the level of the event as either "warning" for a warning
	that needs action, or "error" for an error event that r	event that needs action or "error" for an error event that requires
	equires immediate action.</t>	immediate action.</dd>
	<t hangText=""exDate":">Contains the date and t	<dt>"exDate":</dt>
	ime that a "warning" level has or will become an "error" level.	<dd>Contains the date and time that a "warning" level has or will
	At expiry there MAY be a connection failure or MAY be a login failure.	become an "error" level. At expiry, there <bcp14>MAY</bcp14> be a
	An example is an expired certification that will result in a connection	connection failure or <bcp14>MAY</bcp14> be a login failure. An
	failure or an expired password that may result in a login failure.</t>	example is an expired certification that will result in a connection
	<t hangText=""value":">Identifies the value tha	failure or an expired password that may result in a login
	t resulted in the login security event.	failure.</dd>
	An example is the negotiated insecure cipher suite or t	<dt>"value":</dt>
	he negotiated insecure TLS protocol.</t>	<dd>Identifies the value that resulted in the login security
	<t hangText=""duration":">Defines the duration	event. An example is the negotiated insecure cipher suite or the
	that a statistical event is associated with, ending when the login command was r	negotiated insecure TLS protocol.</dd>
	eceived. The format	<dt>"duration":</dt>
	of the duration is defined by the duration primitive data	<dd>Defines the duration that a statistical event is associated
	type in section 3.2.6 of <xref target="W3C.REC-xmlschema-2-20041028"/>.</t>	with, ending when the login command was received. The format of the
	<t hangText=""lang":">Identifies the negotiated	duration is defined by the duration primitive data type in Section
	language of the free-form description. The format of the language is defined b	3.2.6 of <xref target="W3C.REC-xmlschema-2-20041028"
	y the	format="default"/>.</dd>
	language primitive datatype in section 3.3.3 of <xref target="W3C.REC-xm	<dt>"lang":</dt>
	lschema-2-20041028"/>. The default is "en" (English).</t>	<dd>Identifies the negotiated language of the free-form description.
	</list></t>	The format of the language is defined by the language primitive
		data type in Section 3.3.3 of <xref
	<figure>	target="W3C.REC-xmlschema-2-20041028" format="default"/>. The
	<preamble>Example login security event for password expiration, wher	default is "en" (English).</dd>
	e the current date is 2020-03-25:</preamble>	</dl>
		<t>Example login security event for password expiration, where the
	<artwork><![CDATA[	current date is 2020-03-25:</t>
		<sourcecode type="xml"><![CDATA[
	<loginSec:event	<loginSec:event
	type="password"	type="password"
	level="warning"	level="warning"
	exDate="2020-04-01T22:00:00.0Z"	exDate="2020-04-01T22:00:00.0Z"
	lang="en">	lang="en">
	Password expiration soon	Password expiration soon

	</loginSec:event>]]></artwork>	</loginSec:event>
	</figure>	]]></sourcecode>
		<t>Example login security event for identifying 100 failed logins over
	<figure>	the last day, using the "stat" subtype of "failedLogins":</t>
	<preamble>Example login security event for identifying 100 failed lo	<sourcecode type="xml"><![CDATA[
	gins
	over the last day, using the "stat" sub-type of "failedLogins":</pre
	amble>

	<artwork><![CDATA[
	<loginSec:event	<loginSec:event
	type="stat"	type="stat"
	name="failedLogins"	name="failedLogins"
	level="warning"	level="warning"
	value="100"	value="100"
	duration="P1D">	duration="P1D">
	Excessive invalid daily logins	Excessive invalid daily logins

	</loginSec:event>]]></artwork>	</loginSec:event>
	</figure>	]]></sourcecode>

	</section>	</section>

		<section anchor="loginSecurityPassword" numbered="true" toc="default">
	<section anchor="loginSecurityPassword" title=""[LOGIN-SECURITY]&quot	<name>"[LOGIN-SECURITY]" Password</name>
	; Password">	<t>When the <xref target="RFC5730" format="default"/> <pw>
		element contains the predefined value of "[LOGIN-SECURITY]", the
	<t>When the <xref target="RFC5730"/> <pw> element contains the pre	<loginSec:pw> element overrides the <pw> element, which is
	defined value of "[LOGIN-SECURITY]", the <loginSec:pw> element overrides t	a constant value for the server to use the <loginSec:pw> element
	he <pw> element,	for the password. Similarly, when the <xref target="RFC5730"
	which is a constant value for the server to use the <loginSec:pw>	format="default"/> <newPw> element contains the predefined value
	element for the password.	of "[LOGIN-SECURITY]", the <loginSec:newPw> element overrides
	Similarly, when the <xref target="RFC5730"/> <newPw> element conta	the <newPw> element, which is a constant value for the server to
	ins the predefined value of "[LOGIN-SECURITY]", the <loginSec:newPw> eleme	use the <loginSec:newPW> element for the new password. The
	nt overrides the <newPw> element,	"[LOGIN-SECURITY]" predefined string <bcp14>MUST</bcp14> be supported
	which is a constant value for the server to use the <loginSec:newPW&g	by the server for the client to explicitly indicate to the server
	t; element for the new password.	whether to use <loginSec:pw> element in place of the <xref
	The "[LOGIN-SECURITY]" pre-defined string MUST be supported by the serve	target="RFC5730" format="default"/> <pw> element or to use the
	r for the client to explicitly indicate to the server	<loginSec:newPW> in place of the <xref target="RFC5730"
	whether to use <loginSec:pw> element in place of the <xref target=	format="default"/> <newPW> element. The server <bcp14>MUST
	"RFC5730"/> <pw> element or to use the <loginSec:newPW> in place	NOT</bcp14> allow the client to set the password to the value
	of the <xref target="RFC5730"/> <newPW> element. The server MUST	"[LOGIN-SECURITY]".</t>
	NOT allow the client to set the password to the value "[LOGIN-SECURITY]".</t>
	</section>	</section>

		<section anchor="datestimes" numbered="true" toc="default">
	<section anchor="datestimes" title="Dates and Times">	<name>Dates and Times</name>
		<t>Date and time attribute values <bcp14>MUST</bcp14> be represented
	<t>Date and time attribute values MUST be represented in Universal	in Universal Coordinated Time (UTC) using the Gregorian calendar. The
	Coordinated Time (UTC) using the Gregorian calendar. The extended	extended date-time form using upper case "T" and "Z" characters
	date-time form using upper case "T" and "Z" characters defined in	defined in <xref target="W3C.REC-xmlschema-2-20041028"
	<xref target="W3C.REC-xmlschema-2-20041028"/> MUST be used to represe	format="default"/> <bcp14>MUST</bcp14> be used to represent date-time
	nt date-time	values, as XML Schema does not support truncated date-time forms or
	values, as XML Schema does not support truncated date-time forms or	lower case "T" and "Z" characters.</t>
	lower case "T" and "Z" characters.</t>

	</section>	</section>


	</section>	</section>

		<section anchor="commands" numbered="true" toc="default">
	<section anchor="commands" title="EPP Command Mapping">	<name>EPP Command Mapping</name>
	<t>A detailed description of the EPP syntax and semantics can be found	<t>A detailed description of the EPP syntax and semantics can be found

	in the EPP core protocol specification <xref target="RFC5730"/>.</t>	in the EPP core protocol specification <xref target="RFC5730"
		format="default"/>.</t>
	<section anchor="loginCommand" title="EPP <login> Command">

	<t>This extension defines additional elements to extend the EPP <logi
	n> command and response to be used
	in conjunction with <xref target="RFC5730"/>.</t>

	<t>The EPP <login> command is used to establish a session w
	ith an EPP server. This extension overrides
	the password that is passed with the <xref target="RFC5730"/> &lt
	;pw> or the <newPW> element as defined in
	<xref target="loginSecurityPassword"/>. A <loginSec:loginSec&
	gt; element is sent along with the <xref target="RFC5730"/>
	<login> command and MUST contain at least one of the follow
	ing child elements:</t>

	<t><list hangIndent="4" style="hanging">
	<t hangText="<loginSec:userAgent>:">OPTIONAL client user
	agent information that identifies the client application software, technology, a
	nd operating system used by the server to identify functional or security constr
	aints,
	current security issues, and potential future functional or sec
	urity issues for the client. The server may use the information for real-time i
	dentification and client notification of security issues,
	such as keying off of the client application software for executing securi
	ty rule checks. The server may capture the information to identify future secur
	ity policy issues,
	such as deprecating or removing TLS cipher suites or TLS protocols. The &
	lt;loginSec:userAgent> element MUST contain at least one of the following chi
	ld elements:</t>
	<t><list hangIndent="4" style="hanging">
	<t hangText="<loginSec:app>:">OPTIONAL name of the cl
	ient application software with version if available, such as the name of the cli
	ent SDK "EPP SDK 1.0.0". The <loginSec:app> element value
	can be created by appending the version number to the name of the appl
	ication software, such as the <xref target="RFC5234">Augmented Backus-Naur Form
	(ABNF) grammar</xref> format:
	<list>
	<t>app = name SP version</t>
	<t>name = 1*VCHAR</t>
	<t>version = 1*VCHAR</t>
	</list>
	</t>
	<t hangText="<loginSec:tech>:">OPTIONAL technology us
	ed for the client software with version if available, such as "Vendor Java 11.0.
	6". The <loginSec:tech> element value
	can be created by including the technology vendor, technology name, an
	d technology version, such as the <xref target="RFC5234">Augmented Backus-Naur F
	orm (ABNF) grammar</xref> format:
	<list>
	<t>tech = vendor SP name SP version</t>
	<t>vendor = 1*VCHAR</t>
	<t>name = 1*VCHAR</t>
	<t>version = 1*VCHAR</t>
	</list></t>
	<t hangText="<loginSec:os>:">OPTIONAL client operatin
	g system used with version if available, such as "x86_64 Mac OS X 10.15.2". The
	<loginSec:os> element value
	can be created by including the operating system architecture, operati
	ng system name, and operating system version, such as the <xref target="RFC5234"
	>Augmented Backus-Naur Form (ABNF) grammar</xref> format:
	<list>
	<t>os = arch SP name SP version</t>
	<t>arch = 1*VCHAR</t>
	<t>name = 1*VCHAR</t>
	<t>version = 1*VCHAR</t>
	</list></t>
	</list></t>
	<t hangText="<loginSec:pw>:">OPTIONAL plain text password
	that is case sensitive, has a minimum length of 6 characters, and has a maximum
	length that
	is up to server policy. All leading and trailing whitespace is
	removed, and all internal contiguous whitespace that includes #x9 (tab), #xA (l
	inefeed), #xD (carriage return), and #x20 (space) is
	replaced with a single #x20 (space). This element MUST only be
	set if the <xref target="RFC5730"/> <pw> element is set to the "[LOGIN-SE
	CURITY]" value.</t>
	<t hangText="<loginSec:newPW>:">OPTIONAL plain text new p
	assword that is case sensitive, has a minimum length of 6 characters, and has a
	maximum length that
	is up to server policy. All leading and trailing whitespace is
	removed, and all internal contiguous whitespace that includes #x9 (tab), #xA (l
	inefeed), #xD (carriage return), and #x20 (space) is
	replaced with a single #x20 (space). This element MUST only be
	set if the <xref target="RFC5730"/> <newPW> element is set to the "[LOGIN
	-SECURITY]" value.</t>
	</list></t>

	<t>It is RECOMMENDED that the plain text password in the <logi
	nSec:pw> and <loginSec:newPw> elements use
	printable ASCII characters #x20 (space) - #x7E (~), with high ent
	ropy, such as 128 bits. If non-ASCII characters are supported with the plain te
	xt password, then use
	a standard for passwords with international characters; the Opaqu
	eString PRECIS profile in <xref target="RFC8265"/> is recommended in the
	absence of other considerations.</t>

	<figure>
	<preamble>Example login command that uses the <loginSec:pw> el
	ement instead of the <xref target="RFC5730"/> <pw> element to
	establish the session and includes the <loginSec:userAgent> el
	ement:</preamble>


	<artwork><![CDATA[	<section anchor="loginCommand" numbered="true" toc="default">
		<name>EPP <login> Command</name>
		<t>This extension defines additional elements to extend the EPP
		<login> command and response to be used in conjunction with
		<xref target="RFC5730" format="default"/>.</t>
		<t>The EPP <login> command is used to establish a session with
		an EPP server. This extension overrides the password that is passed
		with the <xref target="RFC5730" format="default"/> <pw> or the
		<newPW> element, as defined in <xref
		target="loginSecurityPassword" format="default"/>. A
		<loginSec:loginSec> element is sent along with the <xref
		target="RFC5730" format="default"/> <login> command and
		<bcp14>MUST</bcp14> contain at least one of the following child
		elements:</t>
		<dl newline="false" indent="4">
		<dt><loginSec:userAgent>:</dt>
		<dd><bcp14>OPTIONAL</bcp14> client user-agent information that
		identifies the client application software, technology, and
		operating system used by the server to identify functional or
		security constraints, current security issues, and potential future
		functional or security issues for the client. The server may use
		the information for real-time identification and client notification
		of security issues, such as keying off of the client application
		software for executing security rule checks. The server may capture
		the information to identify future security policy issues, such as
		deprecating or removing TLS cipher suites or TLS protocols. The
		<loginSec:userAgent> element <bcp14>MUST</bcp14> contain at
		least one of the following child elements:</dd>
		<dt/>
		<dd>
		<dl newline="false" indent="4">
		<dt><loginSec:app>:</dt>
		<dd>
		<t><bcp14>OPTIONAL</bcp14> 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 <xref target="RFC5234"
		format="default"></xref> format:</t>
		<sourcecode type="abnf">
		app = name SP version
		name = 1*VCHAR
		version = 1*VCHAR
		</sourcecode>
		</dd>
		<dt><loginSec:tech>:</dt>
		<dd>
		<t><bcp14>OPTIONAL</bcp14> technology used for the client
		software with version if available, such as "Vendor Java
		11.0.6". 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 <xref target="RFC5234" format="default"></xref>
		format:</t>
		<sourcecode type="abnf">
		tech = vendor SP name SP version
		vendor = 1*VCHAR
		name = 1*VCHAR
		version = 1*VCHAR
		</sourcecode>
		</dd>
		<dt><loginSec:os>:</dt>
		<dd>
		<t><bcp14>OPTIONAL</bcp14> client operating system used with
		version if available, such as "x86_64 Mac OS X 10.15.2". 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 <xref target="RFC5234"
		format="default"></xref> format:</t>
		<sourcecode type="abnf">
		os = arch SP name SP version
		arch = 1*VCHAR
		name = 1*VCHAR
		version = 1*VCHAR
		</sourcecode>
		</dd>
		</dl>
		</dd>
		<dt><loginSec:pw>:</dt>
		<dd><bcp14>OPTIONAL</bcp14> plain text password that is case
		sensitive, has a minimum length of 6 characters, and has a maximum
		length that is up to server policy. All leading and trailing
		whitespace is removed, and all internal contiguous whitespace that
		includes #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20
		(space) is replaced with a single #x20 (space). This element
		<bcp14>MUST</bcp14> only be set if the <xref target="RFC5730"
		format="default"/> <pw> element is set to the
		"[LOGIN-SECURITY]" value.</dd>
		<dt><loginSec:newPW>:</dt>
		<dd><bcp14>OPTIONAL</bcp14> plain text new password that is case
		sensitive, has a minimum length of 6 characters, and has a maximum
		length that is up to server policy. All leading and trailing
		whitespace is removed, and all internal contiguous whitespace that
		includes #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20
		(space) is replaced with a single #x20 (space). This element
		<bcp14>MUST</bcp14> only be set if the <xref target="RFC5730"
		format="default"/> <newPW> element is set to the
		"[LOGIN-SECURITY]" value.</dd>
		</dl>
		<t>It is <bcp14>RECOMMENDED</bcp14> that the plain text password in
		the <loginSec:pw> and <loginSec:newPw> elements use
		printable ASCII characters #x20 (space) - #x7E (~) with high entropy,
		such as 128 bits. If non-ASCII characters are supported with the
		plain text password, then use a standard for passwords with
		international characters; the OpaqueString PRECIS profile in <xref
		target="RFC8265" format="default"/> is recommended in the absence of
		other considerations.</t>
		<t>Example login command that uses the <loginSec:pw> element
		instead of the <pw>
		element (<xref target="RFC5730" format="default"/>) to establish the ses
		sion and includes the
		<loginSec:userAgent> element:</t>
		<sourcecode type=""><![CDATA[
	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <command>	C: <command>
	C: <login>	C: <login>
	C: <clID>ClientX</clID>	C: <clID>ClientX</clID>
	C: <pw>[LOGIN-SECURITY]</pw>	C: <pw>[LOGIN-SECURITY]</pw>
	C: <options>	C: <options>
	C: <version>1.0</version>	C: <version>1.0</version>
	C: <lang>en</lang>	C: <lang>en</lang>
	C: </options>	C: </options>

	skipping to change at line 394 ¶	skipping to change at line 442 ¶
	C: <loginSec:userAgent>	C: <loginSec:userAgent>
	C: <loginSec:app>EPP SDK 1.0.0</loginSec:app>	C: <loginSec:app>EPP SDK 1.0.0</loginSec:app>
	C: <loginSec:tech>Vendor Java 11.0.6</loginSec:tech>	C: <loginSec:tech>Vendor Java 11.0.6</loginSec:tech>
	C: <loginSec:os>x86_64 Mac OS X 10.15.2</loginSec:os>	C: <loginSec:os>x86_64 Mac OS X 10.15.2</loginSec:os>
	C: </loginSec:userAgent>	C: </loginSec:userAgent>
	C: <loginSec:pw>this is a long password</loginSec:pw>	C: <loginSec:pw>this is a long password</loginSec:pw>
	C: </loginSec:loginSec>	C: </loginSec:loginSec>
	C: </extension>	C: </extension>
	C: <clTRID>ABC-12345</clTRID>	C: <clTRID>ABC-12345</clTRID>
	C: </command>	C: </command>

	C:</epp>]]></artwork>	C:</epp>
	</figure>	]]></sourcecode>
		<t>Example login command that uses the <loginSec:pw> element
	<figure>	instead of the <pw>
	<preamble>Example login command that uses the <loginSec:pw> el	element (<xref target="RFC5730" format="default"/>) to
	ement instead of the <xref target="RFC5730"/> <pw> element to	establish the session and that uses the <loginSec:newPW>
	establish the session, and uses the <loginSec:newPW> element i	element instead of the
	nstead of the <xref target="RFC5730"/> <newPW> element to	<newPW> element (<xref target="RFC5730"
	set the new password:</preamble>	format="default"/>) to set the new password:</t>
		<sourcecode type=""><![CDATA[
	<artwork><![CDATA[
	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <command>	C: <command>
	C: <login>	C: <login>
	C: <clID>ClientX</clID>	C: <clID>ClientX</clID>
	C: <pw>[LOGIN-SECURITY]</pw>	C: <pw>[LOGIN-SECURITY]</pw>
	C: <newPW>[LOGIN-SECURITY]</newPW>	C: <newPW>[LOGIN-SECURITY]</newPW>
	C: <options>	C: <options>
	C: <version>1.0</version>	C: <version>1.0</version>
	C: <lang>en</lang>	C: <lang>en</lang>

	skipping to change at line 435 ¶	skipping to change at line 484 ¶
	C: xmlns:loginSec=	C: xmlns:loginSec=
	C: "urn:ietf:params:xml:ns:epp:loginSec-1.0">	C: "urn:ietf:params:xml:ns:epp:loginSec-1.0">
	C: <loginSec:pw>this is a long password	C: <loginSec:pw>this is a long password
	C: </loginSec:pw>	C: </loginSec:pw>
	C: <loginSec:newPW>new password that is still long	C: <loginSec:newPW>new password that is still long
	C: </loginSec:newPW>	C: </loginSec:newPW>
	C: </loginSec:loginSec>	C: </loginSec:loginSec>
	C: </extension>	C: </extension>
	C: <clTRID>ABC-12345</clTRID>	C: <clTRID>ABC-12345</clTRID>
	C: </command>	C: </command>

	C:</epp>]]></artwork>	C:</epp>
	</figure>	]]></sourcecode>
		<t>Example login command that uses the <pw> element (<xref target=
	<figure>	"RFC5730"
	<preamble>Example login command that uses the <xref target="RFC5730"	format="default"/>) to establish the session and
	/> <pw> element to	that uses the <loginSec:newPW> element instead of the <newPW&gt
	establish the session, and uses the <loginSec:newPW> element i	; element (<xref
	nstead of the <xref target="RFC5730"/> <newPW> element to	target="RFC5730" format="default"/>) to set the
	set the new password:</preamble>	new password:</t>
		<sourcecode type=""><![CDATA[
	<artwork><![CDATA[
	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	C: <command>	C: <command>
	C: <login>	C: <login>
	C: <clID>ClientX</clID>	C: <clID>ClientX</clID>
	C: <pw>shortpassword</pw>	C: <pw>shortpassword</pw>
	C: <newPW>[LOGIN-SECURITY]</newPW>	C: <newPW>[LOGIN-SECURITY]</newPW>
	C: <options>	C: <options>
	C: <version>1.0</version>	C: <version>1.0</version>
	C: <lang>en</lang>	C: <lang>en</lang>

	skipping to change at line 474 ¶	skipping to change at line 522 ¶
	C: <extension>	C: <extension>
	C: <loginSec:loginSec	C: <loginSec:loginSec
	C: xmlns:loginSec=	C: xmlns:loginSec=
	C: "urn:ietf:params:xml:ns:epp:loginSec-1.0">	C: "urn:ietf:params:xml:ns:epp:loginSec-1.0">
	C: <loginSec:newPW>new password that is still long	C: <loginSec:newPW>new password that is still long
	C: </loginSec:newPW>	C: </loginSec:newPW>
	C: </loginSec:loginSec>	C: </loginSec:loginSec>
	C: </extension>	C: </extension>
	C: <clTRID>ABC-12345</clTRID>	C: <clTRID>ABC-12345</clTRID>
	C: </command>	C: </command>

	C:</epp>]]></artwork>	C:</epp>
	</figure>	]]></sourcecode>
		<t>Upon a completed login command (success or failed), the extension
	<t>Upon a completed login command (success or failed), the extension M	<bcp14>MUST</bcp14> be included in the response when both of the
	UST be included	following conditions hold:</t>
	in the response when both of the following conditions hold:</t>	<dl newline="false" indent="4">
		<dt>Client supports extension:</dt>
	<t><list hangIndent="4" style="hanging">	<dd>The client supports the extension based on the
	<t hangText="Client supports extension:">	<svcExtension> element of the <login> command.</dd>
	The client supports the extension based on the <svcExtension>	<dt>At least one login security event:</dt>
	element	<dd>The server has identified at least one login security event to
	of the <login> command.</t>	communicate to the client.</dd>
	<t hangText="At least one login security event:">	</dl>
	The server has identified at least one login security event to	<t>The extension to the EPP response uses the
	communicate to the client.</t>	<loginSec:loginSecData> element that contains the following
	</list></t>	child elements:</t>
		<dl newline="false" indent="4">
	<t>The extension to the EPP response uses	<dt><loginSec:event>:</dt>
	the <loginSec:loginSecData> element that contains the following	<dd>One or more <loginSec:event> elements defined in <xref
	child elements:</t>	target="event" format="default"/>.</dd>
		</dl>
	<t><list hangIndent="4" style="hanging">	<t>Example EPP response to a successful login command on 2020-03-25,
	<t hangText="<loginSec:event>:">One or more <loginSec:	where the password will expire in a week:</t>
	event> elements	<sourcecode type=""><![CDATA[
	defined in <xref target="event"/>.</t>
	</list></t>

	<figure>
	<preamble>Example EPP response to a successful login command on 2020
	-03-25, where the password will expire in a week:</preamble>

	<artwork><![CDATA[
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: </result>	S: </result>
	S: <extension>	S: <extension>
	S: <loginSec:loginSecData	S: <loginSec:loginSecData
	S: xmlns:loginSec=	S: xmlns:loginSec=
	S: "urn:ietf:params:xml:ns:epp:loginSec-1.0">	S: "urn:ietf:params:xml:ns:epp:loginSec-1.0">

	skipping to change at line 526 ¶	skipping to change at line 570 ¶
	S: lang="en">	S: lang="en">
	S: Password expiring in a week	S: Password expiring in a week
	S: </loginSec:event>	S: </loginSec:event>
	S: </loginSec:loginSecData>	S: </loginSec:loginSecData>
	S: </extension>	S: </extension>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54321-XYZ</svTRID>	S: <svTRID>54321-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>

	S:</epp>]]></artwork>	S:</epp>
	</figure>	]]></sourcecode>
		<t>Example EPP response to a failed login command where the password
	<figure>	has expired and the new password does not meet the server complexity
	<preamble>Example EPP response to a failed login command where	requirements:</t>
	the password has expired and the new password does not	<sourcecode type=""><![CDATA[
	meet the server complexity requirements:</preamble>

	<artwork><![CDATA[
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="2200">	S: <result code="2200">
	S: <msg>Authentication error</msg>	S: <msg>Authentication error</msg>
	S: </result>	S: </result>
	S: <extension>	S: <extension>
	S: <loginSec:loginSecData	S: <loginSec:loginSecData
	S: xmlns:loginSec=	S: xmlns:loginSec=
	S: "urn:ietf:params:xml:ns:epp:loginSec-1.0">	S: "urn:ietf:params:xml:ns:epp:loginSec-1.0">

	skipping to change at line 563 ¶	skipping to change at line 604 ¶
	S: level="error">	S: level="error">
	S: New password does not meet complexity requirements	S: New password does not meet complexity requirements
	S: </loginSec:event>	S: </loginSec:event>
	S: </loginSec:loginSecData>	S: </loginSec:loginSecData>
	S: </extension>	S: </extension>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54321-XYZ</svTRID>	S: <svTRID>54321-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>

	S:</epp>]]></artwork>	S:</epp>
	</figure>	]]></sourcecode>
		<t>Example EPP response to a successful login command where
	<figure>	there is a set of login security events:</t>
	<preamble>Example EPP response to a successful login command where	<sourcecode type=""><![CDATA[
	there is a set of login security events:</preamble>

	<artwork><![CDATA[
	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>	S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">	S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
	S: <response>	S: <response>
	S: <result code="1000">	S: <result code="1000">
	S: <msg>Command completed successfully</msg>	S: <msg>Command completed successfully</msg>
	S: </result>	S: </result>
	S: <extension>	S: <extension>
	S: <loginSec:loginSecData	S: <loginSec:loginSecData
	S: xmlns:loginSec=	S: xmlns:loginSec=
	S: "urn:ietf:params:xml:ns:epp:loginSec-1.0">	S: "urn:ietf:params:xml:ns:epp:loginSec-1.0">

	skipping to change at line 616 ¶	skipping to change at line 654 ¶
	S: name="failedLogins"	S: name="failedLogins"
	S: level="warning"	S: level="warning"
	S: value="100"	S: value="100"
	S: duration="P1D">	S: duration="P1D">
	S: Excessive invalid daily logins	S: Excessive invalid daily logins
	S: </loginSec:event>	S: </loginSec:event>
	S: <loginSec:event	S: <loginSec:event
	S: type="custom"	S: type="custom"
	S: name="myCustomEvent"	S: name="myCustomEvent"
	S: level="warning">	S: level="warning">

	S: A custom login security event occured	S: A custom login security event occurred
	S: </loginSec:event>	S: </loginSec:event>
	S: </loginSec:loginSecData>	S: </loginSec:loginSecData>
	S: </extension>	S: </extension>
	S: <trID>	S: <trID>
	S: <clTRID>ABC-12345</clTRID>	S: <clTRID>ABC-12345</clTRID>
	S: <svTRID>54321-XYZ</svTRID>	S: <svTRID>54321-XYZ</svTRID>
	S: </trID>	S: </trID>
	S: </response>	S: </response>

	S:</epp>]]></artwork>	S:</epp>
	</figure>	]]></sourcecode>

	</section>	</section>
	<!-- end LOGIN command -->	<!-- end LOGIN command -->

	</section>	</section>


	<!-- EPP command mapping -->	<!-- EPP command mapping -->


	<section anchor="syntax" title="Formal Syntax">	<section anchor="syntax" numbered="true" toc="default">
		<name>Formal Syntax</name>
	<t>The EPP Login Security Extension schema is presented here.</t>	<t>The EPP Login Security Extension schema is presented here.</t>


	<t>The formal	<t>The formal

	syntax presented here is a complete XML schema representation of the objec t	syntax shown here is a complete XML Schema representation of the object
	mapping suitable for automated validation of EPP XML instances. The	mapping suitable for automated validation of EPP XML instances. The

	BEGIN and END tags are not part of the XML schema; they are used to note t	<CODE BEGINS> and <CODE ENDS> tags are not part of the XML Sch
	he	ema; they are used to note the
	beginning and ending of the XML schema for URI registration purposes.</t>	beginning and ending of the XML Schema for URI registration purposes.</t>
		<section numbered="true" toc="default">
	<section title="Login Security Extension Schema">	<name>Login Security Extension Schema</name>
		<sourcecode type="xml" markers="true"><![CDATA[
	<figure>
	<artwork><![CDATA[
	BEGIN
	<?xml version="1.0" encoding="UTF-8"?>	<?xml version="1.0" encoding="UTF-8"?>
	<schema xmlns="http://www.w3.org/2001/XMLSchema"	<schema xmlns="http://www.w3.org/2001/XMLSchema"
	xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"	xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
	xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"	xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
	xmlns:loginSec="urn:ietf:params:xml:ns:epp:loginSec-1.0"	xmlns:loginSec="urn:ietf:params:xml:ns:epp:loginSec-1.0"
	targetNamespace="urn:ietf:params:xml:ns:epp:loginSec-1.0"	targetNamespace="urn:ietf:params:xml:ns:epp:loginSec-1.0"
	elementFormDefault="qualified">	elementFormDefault="qualified">
	<!--	<!--
	Import common element types.	Import common element types.
	-->	-->

	skipping to change at line 764 ¶	skipping to change at line 796 ¶
	<simpleType name="levelEnum">	<simpleType name="levelEnum">
	<restriction base="token">	<restriction base="token">
	<enumeration value="warning" />	<enumeration value="warning" />
	<enumeration value="error" />	<enumeration value="error" />
	</restriction>	</restriction>
	</simpleType>	</simpleType>
	<!--	<!--
	End of schema.	End of schema.
	-->	-->
	</schema>	</schema>

	END]]></artwork>	]]></sourcecode>
	</figure>
	</section>	</section>
	</section>	</section>

		<section anchor="IANA" numbered="true" toc="default">
	<section anchor="IANA" title="IANA Considerations">	<name>IANA Considerations</name>
		<section anchor="IANA-XML-Namespace" numbered="true" toc="default">
	<section anchor="IANA-XML-Namespace" title="XML Namespace">	<name>XML Namespace</name>
	<t>	<t>This document uses URNs to describe XML namespaces and XML schemas
	This document uses URNs to describe XML namespaces and XML schemas	conforming to a registry mechanism described in <xref target="RFC3688"
	conforming to a registry mechanism described in <xref target="RFC36	format="default"/>. The following URI assignment has been made by
	88"/>.	IANA:</t>
	The following URI assignment is requested of IANA:	<t>Registration request for the loginSec namespace:</t>
	</t>	<dl newline="false" spacing="compact">
		<dt>URI:</dt>
	<t>Registration request for the loginSec namespace:</t>	<dd>urn:ietf:params:xml:ns:epp:loginSec-1.0</dd>
		<dt>Registrant Contact:</dt>
	<t><list>	<dd>IESG</dd>
	<t>URI: urn:ietf:params:xml:ns:epp:loginSec-1.0</t>	<dt>XML:</dt>
		<dd>None. Namespace URIs do not represent an XML specification.</dd>
	<t>Registrant Contact: IESG</t>	</dl>
		<t>Registration request for the loginSec XML Schema:</t>
	<t>XML: None. Namespace URIs do not represent an XML specification.</t>	<dl newline="false" spacing="compact">
	</list></t>	<dt>URI:</dt>
		<dd>urn:ietf:params:xml:schema:epp:loginSec-1.0</dd>
	<t>Registration request for the loginSec XML schema:</t>	<dt>Registrant Contact:</dt>
		<dd>IESG</dd>
	<t><list>	<dt>XML:</dt>
	<t>URI: urn:ietf:params:xml:schema:epp:loginSec-1.0</t>	<dd>See the "Formal Syntax" section of this document.</dd>
		</dl>
	<t>Registrant Contact: IESG</t>	</section>
		<section anchor="EPP-Extension-Registry" numbered="true" toc="default">
	<t>XML: See the "Formal Syntax" section of this document.</t>	<name>EPP Extension Registry</name>
		<t>The EPP extension described in this document has been registered
	</list></t>	by IANA in the "Extensions for the Extensible Provisioning
		Protocol (EPP)" registry described in <xref
	</section>	target="RFC7451" format="default"/>. The details of the registration
		are as follows:</t>
	<section anchor="EPP-Extension-Registry" title="EPP Extension Registry">	<dl newline="false" spacing="compact">
		<dt>Name of Extension:</dt>
	<t>	<dd>"Login Security Extension for the Extensible
	The EPP extension described in this document should be registered by	Provisioning Protocol (EPP)"</dd>
	the IANA in the EPP Extension Registry described in <xref target="RFC7451"/>.	<dt>Document status:</dt>
	The	<dd>Standards Track</dd>
	details of the registration are as follows:	<dt>Reference:</dt>
	</t>	<dd>RFC 8807</dd>
		<dt>Registrant Name and Email Address:</dt>
	<t>	<dd>IESG, <iesg@ietf.org></dd>
	Name of Extension: "Login Security Extension for the Extensible Provisio	<dt>Top-Level Domains(TLDs):</dt>
	ning Protocol (EPP)"	<dd>Any</dd>
	</t>	<dt>IPR Disclosure:</dt>
		<dd>None</dd>
	<t>	<dt>Status:</dt>
	Document status: Standards Track	<dd>Active</dd>
	</t>	<dt>Notes:</dt>
		<dd>None</dd>
	<t>	</dl>
	Reference: (insert reference to RFC version of this document)
	</t>

	<t>
	Registrant Name and Email Address: IESG, <iesg@ietf.org>
	</t>

	<t>
	TLDs: Any
	</t>

	<t>
	IPR Disclosure: None
	</t>

	<t>
	Status: Active
	</t>

	<t>
	Notes: None
	</t>

	</section>

	</section>

	<section anchor="Implementation" title="Implementation Status">
	<t>Note to RFC Editor: Please remove this section and the reference to
	<xref target="RFC7942">RFC 7942</xref> before publication.</t>
	<t>This section records the status of known implementations of the
	protocol defined by this specification at the time of posting of
	this Internet-Draft, and is based on a proposal described in <xref target=
	"RFC7942">RFC
	7942</xref>. The description of implementations in this section is
	intended to assist the IETF in its decision processes in
	progressing drafts to RFCs. Please note that the listing of any
	individual implementation here does not imply endorsement by the
	IETF. Furthermore, no effort has been spent to verify the
	information presented here that was supplied by IETF contributors.
	This is not intended as, and must not be construed to be, a
	catalog of available implementations or their features. Readers
	are advised to note that other implementations may exist.</t>
	<t>According to <xref target="RFC7942">RFC 7942</xref>, "this will allow r
	eviewers and working
	groups to assign due consideration to documents that have the
	benefit of running code, which may serve as evidence of valuable
	experimentation and feedback that have made the implemented
	protocols more mature. It is up to the individual working groups
	to use this information as they see fit".</t>
	<section title="Verisign EPP SDK">
	<t>Organization: Verisign Inc.</t>
	<t>Name: Verisign EPP SDK</t>
	<t>Description: The Verisign EPP SDK includes both a full client impleme
	ntation
	and a full server stub implementation of draft-ietf-regext-login-securit
	y.</t>
	<t>Level of maturity: Development</t>
	<t>Coverage: All aspects of the protocol are implemented.</t>
	<t>Licensing: GNU Lesser General Public License</t>
	<t>Contact: jgould@verisign.com</t>
	<t>URL: https://www.verisign.com/en_US/channel-resources/domain-registry
	-products/epp-sdks</t>
	</section>	</section>
	</section>	</section>

		<section anchor="Security" numbered="true" toc="default">
	<section anchor="Security" title="Security Considerations">	<name>Security Considerations</name>
	<t>The Security Considerations of <xref target="RFC5730"/> apply in this d	<t>The security considerations of <xref target="RFC5730"
	ocument, and this document enhances these considerations.</t>	format="default"/> apply in this document, and this document enhances
	<t>The extension leaves the password (<pw> element) and new password	these considerations.</t>
	(<newPW> element) minimum length	<t>The extension leaves the password (<pw> element) and new
	greater than 6 characters and the maximum length up to server policy. The	password (<newPW> element) minimum length greater than 6
	server SHOULD enforce minimum and maximum length requirements that are	characters and the maximum length up to server policy. The server
	appropriate for their operating environment. One example of a guideline f	<bcp14>SHOULD</bcp14> enforce minimum and maximum length requirements
	or password length policies can be found in section 5 of	that are appropriate for their operating environment. One example of a
	<eref target="https://pages.nist.gov/800-63-3/sp800-63b.html">NIST Special	guideline for password length policies can be found in Section 5 of
	Publication 800-63B</eref>.</t>	<eref target="https://pages.nist.gov/800-63-3/sp800-63b.html">NIST
	<t>The client SHOULD NOT decrease	Special Publication 800-63B</eref>.</t>
	the security of a new password by decreasing the length of the current pas	<t>The client <bcp14>SHOULD NOT</bcp14> decrease
	sword. For example, a client with a 20 character password set using	the security of a new password by decreasing the length of the current
	the extension, should not use the login command in <xref target="RFC5730"/	password. For example, a client with a 20-character password set using
	> without using the extension, to set a new password that is less than or equal	the extension should not use the login command in <xref
	to 16 characters.</t>	target="RFC5730" format="default"/> without using the extension to set
	<t>The extension provides an extensible list of login security events to i	a new password that is less than or equal to 16 characters.</t>
	nform clients of connection and login warnings and errors.	<t>The extension provides an extensible list of login security events to
	The server returning of security events to unauthenticated users needs to	inform clients of connection and login warnings and errors. The server
	take into account the security/privacy issues of	returning of security events to unauthenticated users needs to take into
	returning information to potential attackers.</t>	account the security/privacy issues of returning information to
	<t>The user agent information represents the client system of a system-to-	potential attackers.</t>
	system interface, so the user	<t>The user-agent information represents the client system of a
	agent information MUST NOT provide any ability to track individual users	system-to-system interface, so the user-agent information <bcp14>MUST
	or classes of users.</t>	NOT</bcp14> provide any ability to track individual users or classes of
	</section>	users.</t>

	<section anchor="Acknowledgements" title="Acknowledgements">
	<t>The authors wish to thank the following persons for their feedback and
	suggestions:</t>
	<t><list style="symbols">
	<t>Martin Casanova</t>
	<t>Scott Hollenbeck</t>
	<t>Barry Leiba</t>
	<t>Patrick Mevzek</t>
	<t>Joseph Yee</t>
	</list></t>

	</section>	</section>


	</middle>	</middle>


	<!-- ***BACK MATTER *** -->	<!-- ***BACK MATTER *** -->

	<back>	<back>

	<!-- References split into informative and normative -->

	<!-- There are 2 ways to insert reference entries from the citation librarie
	s:
	1. define an ENTITY at the top, and use "ampersand character"RFC2629; here
	(as shown)
	2. simply use a PI "less than character"?rfc include="reference.RFC.2119.xm
	l"?> here
	(for I-Ds: include="reference.I-D.narten-iana-considerations-rfc2434bis.
	xml")

	Both are cited textually in the same manner: by using xref elements.
	If you use the PI option, xml2rfc will, by default, try to find included fi
	les in the same
	directory as the including file. You can also define the XML_LIBRARY enviro
	nment variable
	with a value containing a set of directories to search. These can be eithe
	r in the local
	filing system or remote ones accessed by http (http://domain/dir/... ).-->

	<references title="Normative References">

	&RFC2119;

	&RFC3688;

	&RFC5730;

	&RFC7942;

	&RFC8174;

	&W3C.REC-xmlschema-2-20041028;

	</references>

	<references title="Informative References">

	&RFC5234;


	&RFC7451;	<references>
		<name>References</name>
		<references>
		<name>Normative References</name>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.2119.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.3688.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.5730.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8174.xml"/>


	&RFC8265;	<reference anchor="W3C.REC-xmlschema-2-20041028" target="http://www.w3.o
		rg/TR/2004/REC-xmlschema-2-20041028" xml:base="https://xml2rfc.tools.ietf.org/pu
		blic/rfc/bibxml4/reference.W3C.REC-xmlschema-2-20041028.xml">
		<front>
		<title>XML Schema Part 2: Datatypes Second Edition</title>
		<seriesInfo name="W3C Recommendation" value="REC-xmlschema-2-2004102
		8"/>
		<author initials="P." surname="Biron" fullname="Paul V. Biron">
		<organization/>
		</author>
		<author initials="A." surname="Malhotra" fullname="Ashok Malhotra">
		<organization/>
		</author>
		<date month="October" year="2004"/>
		</front>
		</reference>


		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxm
		l/reference.RFC.5234.xml"/>
		</references>
		<references>
		<name>Informative References</name>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.7451.xml"/>
		<xi:include href="https://xml2rfc.tools.ietf.org/public/rfc/bibxml/refer
		ence.RFC.8265.xml"/>
		</references>
	</references>	</references>

		<section anchor="Acknowledgements" numbered="false" toc="default">
	<section title="Change History">	<name>Acknowledgements</name>
		<t>The authors wish to thank the following persons for their feedback
	<t>[[RFC Editor: Please remove this section.]]</t>	and suggestions: <contact fullname="Martin Casanova"/>, <contact
		fullname="Scott Hollenbeck"/>, <contact fullname="Barry Leiba"/>,
	<section title="Change from 00 to 01" anchor="change-00-to-01">	<contact fullname="Patrick Mevzek"/>, and <contact fullname="Joseph
	<t><list style="numbers">	Yee"/>.</t>
	<t>Based on the feedback from Patrick Mevzek and a proposal from Scott H
	ollenbeck, changed the minimum length of the password from 8 to 6, revised the d
	escription of the password,
	and added text in the Security Considerations section for the server pas
	sword length policy.</t>
	</list></t>
	</section>
	<section title="Change from 01 to 02" anchor="change-01-to-02">
	<t><list style="numbers">
	<t>Changed the XML namespace from urn:ietf:params:xml:ns:loginSec-0.3 to
	urn:ietf:params:xml:ns:epp:loginSec-0.3,
	and changed the XML schema registration from urn:ietf:params:xml:ns:logi
	nSec-0.3 to urn:ietf:params:xml:schema:epp:loginSec-0.3 based
	on a request from IANA with draft-ietf-regext-allocation-token.</t>
	</list></t>
	</section>
	<section title="Change from 02 to 03" anchor="change-02-to-03">
	<t><list style="numbers">
	<t>Updates based on the review by Patrick Mevzek, that include:
	<list style="numbers">
	<t>Fix the inconsistent case for newPW, that required a global chang
	e in the draft text and an update to the XML schema to "urn:ietf:params:xml:ns:l
	oginSec-0.3".</t>
	<t>Changed "contains the following child elements" to "MUST contain
	at least one of the following child elements", section "EPP <login> Comman
	d" to ensure that
	an empty <loginSec:loginSec> element is not passed.</t>
	<t>Add "The client SHOULD NOT decrease the security of a new passwor
	d by decreasing the length of the current password." along with an example to th
	e "Security Considerations" section.</t>
	</list>
	</t>
	</list></t>
	</section>

	<section title="Change from 03 to REGEXT 00" anchor="change-03-to-WG00">
	<t><list style="numbers">
	<t>Changed to regext working group draft by changing draft-gould-regext-
	login-security to draft-ietf-regext-login-security.</t>
	</list></t>
	</section>

	<section title="Change from REGEXT 00 to REGEXT 01" anchor="change-WG00-to-
	WG01">
	<t><list style="numbers">
	<t>Changed the <loginSec:userAgent> element to be structured with
	the <loginSec:app>, <loginSec:tech>, and <loginSec:os> sub-ele
	ments. This was based on the
	feedback from Martin Casanova. This resulted in the need to change the
	XML namespace from urn:ietf:params:xml:ns:epp:loginSec-0.3 to urn:ietf:params:xm
	l:ns:epp:loginSec-0.4.</t>
	</list></t>
	</section>

	<section title="Change from REGEXT 01 to REGEXT 02" anchor="change-WG01-to-
	WG02">
	<t><list style="numbers">
	<t>Updated the Implementation Status section from "TBD" to include the Ve
	risign EPP SDK implementation.</t>
	</list></t>
	</section>

	<section title="Change from REGEXT 02 to REGEXT 03" anchor="change-WG02-to-
	WG03">
	<t><list style="numbers">
	<t>Revised the description of the "duration" attribute to clarify that i
	t ends when the
	login command was received and to clarify the format, based on the feedb
	ack from Martin Casanova.</t>
	<t>Revised the sentence 'Upon a completed login command (success or fail
	ed), the extension MUST
	be included in the response based on the following conditions:' to 'Up
	on a completed login command (success or failed),
	the extension MUST be included in the response based on both of the fo
	llowing conditions:' based on the feedback from Patrick Mevzek.</t>
	<t>Updates based on the review by Joseph Yee, that include:
	<list style="numbers">
	<t>Revised the description of the <loginSec:event> "name" attr
	ibute read 'Used to define a sub-type when the "type" attribute is not "custom"
	or the full type name when the "type" attribute is "custom"'.
	The definition of the "stat" type was updated to 'Provides a login s
	ecurity statistical warning that MUST set the "name" attribute to the name of th
	e statistic.'</t>
	<t>Added the following sentence 'The server MUST NOT allow the clien
	t to set the password to the value "[LOGIN-SECURITY]".' to address the corner ca
	se where the constant is used as the password.</t>
	<t>Revised the description of the <loginSec:userAgent> element
	to read 'The <loginSec:userAgent> element MUST contain at least one of th
	e following child elements:'.</t>
	</list>
	</t>
	<t>Revised the description of the <loginSec:userAgent> to match th
	e child elements that can be passed, by changing "client software" to "client ap
	plication software" and change "language" to "technology".</t>
	<t>Changed the XML namespace from urn:ietf:params:xml:ns:epp:loginSec-0.
	4 to urn:ietf:params:xml:ns:epp:loginSec-1.0.</t>
	</list></t>
	</section>

	<section title="Change from REGEXT 03 to REGEXT 04" anchor="change-WG03-to-W
	G04">
	<t>Updates based on the review by Joseph Yee, that include:
	<list style="numbers">
	<t>Update the definition of the "stat" security event type to refere
	nce sub-type to match the language for the "name" attribute.</t>
	<t>Added the sentence 'The "name" attribute MUST be set when the "ty
	pe" attribute is "stat" or "custom".' to the definition of the "name" attribute
	for clarity.</t>
	<t>Update the definition of the "userAgentType" in the XML schema to
	require at least one sub-element using a <choice> element.</t>
	</list>
	</t>
	</section>

	<section title="Change from REGEXT 04 to REGEXT 05" anchor="change-WG04-to-W
	G05">
	<t>Updates based on the review by Barry Leiba, that include:
	<list style="numbers">
	<t>In section 1.1, updated to use BCP 14 boilerplate and references
	as defined in RFC 8174.</t>
	<t>In section 1.1, change "REQUIRED" to "required".</t>
	<t>Keep the "Migration to Newer Versions of This Extension" section
	by removing the note for removal to the RFC Editor.</t>
	<t>In section 3.1, change "MAY be multiple events returned that prov
	ides information" to "MAY be multiple events returned that provide information".
	</t>
	<t>In section 3.1, change "free form" to "free-form".</t>
	<t>In section 3.1, change "The enumerated list of "type" v
	alues include:" to "The enumerated list of "type" values includes:".</
	t>
	<t>In section 3.1, change "Identifies the language of the free-form
	description if the negotiated language is something other than the
	default value of "en" (English)." to "Identifies the nego
	tiated language of the free-form description. The default is "en" (English).</t
	>
	<t>In section 3.1, change example description from "Examp
	le login security event for a password expiring in a week:" to
	"Example login security event for password expiration, wh
	ere the current date is 2018-03-25:".</t>
	<t>In section 4.1, change "Example EPP response to a succ
	essful login command where the password will expire in a week:" to
	"Example EPP response to a successful login command on 20
	18-03-25, where the password will expire in a week:".</t>
	</list>
	</t>
	</section>

	<section title="Change from REGEXT 05 to REGEXT 06" anchor="change-WG05-to-W
	G06">
	<t>Updates based on the review by Brian Carpenter, that include:
	<list style="numbers">
	<t>In section 1, change the references to RFC 5730 to use links.</t>
	<t>In section 2, change "(for a temporary migration period)" to "(fo
	r a temporary migration period up to server policy)".</t>
	</list>
	</t>
	</section>

	<section title="Change from REGEXT 06 to REGEXT 07" anchor="change-WG06-to-W
	G07">
	<t><list style="numbers">
	<t>Updates based on feedback from Barry Leiba, added recommendations on
	the characters used for the plain text password.
	Recommended the use of printable ASCII passwords and
	if non-ASCII characters are supported, to use a standard for passwords w
	ith international characters, such as
	the OpaqueString PRECIS profile in <xref target="RFC8265"/>.</t>
	<t>Based on the feedback from Carlos Pignataro, added "[[RFC Editor: Ple
	ase remove this section.]]" to the "Change History" section.</t>
	</list></t>
	</section>

	<section title="Change from REGEXT 07 to REGEXT 08" anchor="change-WG07-to-W
	G08">
	<t><list style="numbers">
	<t>Based on feedback from Eric Vyncke during the IESG review, changed <x
	ref target="RFC8174"/> from the informative references into the normative refere
	nces.</t>
	<t>Based on feedback from Alissa Cooper during the IESG review, changed
	the sentence
	"One schema is presented here that is the EPP Login Security Extension
	schema." in section 5
	to "The EPP Login Security Extension schema is presented here.".</t>
	<t>Changed "sever policy" to "server policy" in section 8.</t>
	<t>Updates based on feedback from Roman Danyliw during the IESG review:
	<list style="numbers">
	<t>Changed "pasword" to "password" in section 1.</t>
	<t>In section 3.1, added a reference to section 3.3.3 of <xref targe
	t="W3C.REC-xmlschema-2-20041028"/> for the format of the "lang" attribute.
	Added the corresponding section (3.2.6) for the "duration" attribute
	.</t>
	<t>Added the "XML" prefix for each reference to "schema" in the intr
	oduction of section 5.</t>
	<t>Added the leading sentence "The Security Considerations of <xref
	target="RFC5730"/> apply in this document, and this document enhances these cons
	iderations." to section 8.</t>
	<t>Added the sentence 'The possible set of "name" values, by event t
	ype, can be discovered / negotiated out of band to EPP or using a
	separate EPP extension designed to provide server policy informati
	on to the client.'
	to the description of the "name" attribute.</t>
	<t>Added a description of how to create the <loginSec:app>, &l
	t;loginSec:tech>, and <loginSec:os> values using ABNF.</t>
	</list>
	</t>
	<t>Updates based on feedback from Alexey Melnikov during the IESG review
	:
	<list style="numbers">
	<t>Added a description of "whitespace" to section 1.1.</t>
	<t>Added a description of the usage of the user agent information
	in section 4.1.</t>
	</list>
	</t>
	<t>Updates based on feedback from Benjamin Kaduk during the IESG review:
	<list style="numbers">
	<t>Added "A newer version of the extension is expected to use an XML
	namespace with a higher version number than the prior versions." to the first p
	aragraph of section 2.</t>
	<t>In section 3.1, replace the sentence "There MAY be multiple event
	s returned that provide information for the client to address." with "The <lo
	ginSec:event> element
	is contained in a list of one or more elements in the <loginSec:l
	oginSecData> element,
	so there MAY be multiple events returned that provide information fo
	r the client to address."</t>
	<t>In section 3.1, for the "exDate" attribute, replace the sentence
	"At expiry there MAY be an error to connect or MAY be an error to login." with
	"At expiry there MAY be a connection failure or MAY be a login failu
	re." and a similar change to the following sentence.</t>
	<t>In section 3.1, replace the description of the "cipher" type and
	the "tlsProtocol" type.</t>
	<t>In section 3.1, add a sentence that the "exDate" attribute MUST b
	e set for the "password" type and the "certificate" type.</t>
	<t>Updates the dates by replacing 2018 with 2020.</t>
	<t>In section 3.2, update the MUST override sentences for the <lo
	ginSec:pw> and the <loginSec:newPw> elements.</t>
	<t>In section 4.1, update "OPTIONAL client user agent" with "OPTIONA
	L client user agent information" for the description of the <loginSec:userAge
	nt> element.</t>
	<t>In section 4.1, replace "MUST only be used" to "MUST only be set"
	for the <loginSec:pw> and <loginSec:newPw> elements.</t>
	<t>Updated references of "x86_64 Mac OS X 10.11.6" to "x86_64 Mac OS
	X 10.15.2".</t>
	<t>In section 4.1, replace "MUST be included in the response based o
	n both of the following conditions" with
	"MUST be included in the response when both of the following condi
	tions hold".</t>
	<t>In section 4.1, update the "exDate" for the "password" security e
	vent error to be
	"2020-03-24T22:00:00.0Z" so that it's prior to the date 2020-03-25
	reference previously.</t>
	<t>In section 8, add the sentence "The server returning of security
	events to unauthenticated users
	needs to take into account the security/privacy issues of returnin
	g information to potential attackers."
	to the end of the last paragraph.</t>
	<t>In section 8, change "minimum length beyond 6 characters" to "min
	imum length greater than 6 characters".</t>
	<t>In section 8, add the sentence "The user agent information repres
	ents the client system of a system-to-system interface, so the user
	agent information MUST NOT provide any ability to track individual
	users or classes of users."</t>
	</list>
	</t>
	</list></t>
	</section>

	<section title="Change from REGEXT 08 to REGEXT 09" anchor="change-WG08-to-W
	G08">
	<t><list style="numbers">
	<t>Based on feedback from Barry Leiba in responding to Benjamin Kaduk's
	discuss item,
	changed "It is recommended that the plain text..." to "It is RECOMMEND
	ED that the plain text..." and
	"If non-ASCII characters are supported with the plain text password, t
	hen use a standard for passwords
	with international characters, such as the OpaqueString PRECIS profile
	in [RFC8265]." to
	"If non-ASCII characters are supported with the plain text password, t
	hen use a standard for passwords
	with international characters; the OpaqueString PRECIS profile in [RFC
	8265] is recommended in the absence of
	other considerations."</t>
	</list></t>
	</section>

	<section title="Change from REGEXT 09 to REGEXT 10" anchor="change-WG09-to-W
	G10">
	<t><list style="numbers">
	<t>Based on feedback from Benjamin Kaduk, added the sentence
	"EPP <xref target="RFC5730"/> includes a maximum password length of 16
	characters that inhibits
	implementing stronger password security policies with higher entropy.
	" to the Introduction.</t>
	</list></t>
	</section>	</section>


	</section>

	</back>	</back>


	<!-- vim: set ts=2 sw=2 expandtab: -->
	</rfc>	</rfc>

End of changes. 69 change blocks.
	1013 lines changed or deleted	535 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/