Login Security Extension for the Extensible Provisioning Protocol (EPP)VeriSign, Inc.12061 Bluemont WayRestonVA20190United States of Americajgould@verisign.comhttp://www.verisign.comVeriSign, Inc.12061 Bluemont WayRestonVA20190United States of Americampozun@verisign.comhttp://www.verisign.comThe 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 additional security
features to the EPP login command and response.Status of This Memo
This is an Internet Standards Track document.
This document is a product of the Internet Engineering Task Force
(IETF). It represents the consensus of the IETF community. It has
received public review and has been approved for publication by
the Internet Engineering Steering Group (IESG). Further
information on Internet Standards is available in Section 2 of
RFC 7841.
Information about the current status of this document, any
errata, and how to provide feedback on it may be obtained at
.
Copyright Notice
Copyright (c) 2020 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
() in effect on the date of
publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with
respect to this document. Code Components extracted from this
document must include Simplified BSD License text as described in
Section 4.e of the Trust Legal Provisions and are provided without
warranty as described in the Simplified BSD License.
Table of Contents
. Introduction
. Conventions Used in This Document
. Migrating to Newer Versions of This Extension
. Object Attributes
. Event
. "[LOGIN-SECURITY]" Password
. Dates and Times
. EPP Command Mapping
. EPP <login> Command
. Formal Syntax
. Login Security Extension Schema
. IANA Considerations
. XML Namespace
. EPP Extension Registry
. Security Considerations
. References
. Normative References
. Informative References
Acknowledgements
Authors' Addresses
IntroductionThis document describes an Extensible Provisioning Protocol (EPP)
extension for enhancing the security of the EPP login command in EPP
. EPP includes a maximum password length of 16 characters,
which inhibits implementing stronger password security policies with
higher entropy. 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 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 password
complexity, login security statistical warning, and a custom event. The
attributes supported by the security events include an identified event
type or a subtype, an indicated 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.Conventions Used in This Document
The key words "MUST", "MUST NOT",
"REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT",
"RECOMMENDED", "NOT RECOMMENDED",
"MAY", and "OPTIONAL" in this document are
to be interpreted as
described in BCP 14
when, and only when, they appear in all capitals, as shown here.
XML is case sensitive. Unless stated otherwise, XML specifications
and examples provided in this document MUST be
interpreted in the character case presented in order to develop a
conforming implementation.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."loginSec-1.0" is used as an abbreviation for
"urn:ietf:params:xml:ns:epp:loginSec-1.0". The XML namespace prefix
"loginSec" is used, but implementations MUST NOT depend on
it. Instead, they are to employ
a proper namespace-aware XML parser and serializer to interpret and
output the XML documents."whitespace" is defined by the XML Schema whiteSpace data type in
, which
only includes the ASCII whitespace characters #x9 (tab), #xA
(linefeed), #xD (carriage return), and #x20 (space).Migrating to Newer Versions of This ExtensionServers that implement this extension SHOULD provide a way for
clients to progressively update their implementations when a new
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
the prior versions.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
<svcExtension> element of the <login> command.If a client requests multiple versions of the extension at login,
then, when preparing responses to commands that 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 that do include extension
elements, the server SHOULD only include extension elements for the
extension versions present in the command.Object AttributesThis extension adds additional elements to login command and response. Only those new elements
are described here.EventA security event using the <loginSec:event> element
represents either a warning or error identified by the server after
the client has connected and submitted the login command. The
<loginSec:event> element is contained in a list of one or more
elements in the <loginSec:loginSecData> element, so there
MAY be multiple events returned that provide
information for the client to address. The <loginSec:event>
MAY include a free-form description. All of the
security events use a consistent set of attributes, where the exact
set of applicable attributes is based on the event type. The supported
set of <loginSec:event> element attributes include:
"type":
A REQUIRED attribute that defines the type of
security event. The enumerated list of "type" values includes:
"password":
Identifies a password expiry event where the password
expires in the future or has expired based on the "exDate" date
and time. The "exDate" attribute MUST be set with
the password expiry date and time.
"certificate":
Identifies a client certificate expiry event where the
client certificate will expire at the "exDate" date and
time. The "exDate" attribute MUST be set with the
certificate expiry date and time.
"cipher":
Identifies the use of an insecure or deprecated TLS cipher
suite. The "name" attribute MUST be set with the
name of the cipher suite, which is free-form and is not expected
to be parsed and automatically addressed by the client. An
example of cipher suite names can be found in the TLS Cipher
Suites of the "Transport
Layer Security (TLS) Parameters" registry.
"tlsProtocol":
Identifies the use of an insecure or deprecated TLS
protocol. The "name" attribute MUST be set with
the name of the TLS protocol, which is free-form and is not
expected to be parsed and automatically addressed by the
client.
"newPW":
The new password does not meet the server password
complexity requirements.
"stat":
Provides a login security statistical warning that
MUST set the "name" attribute to the name of the
statistic subtype.
"custom":
Custom event type that MUST set the "name"
attribute with the custom event type name.
"name":
Used to define a subtype when the "type" attribute is not
"custom" or the full type name when the "type" attribute is
"custom". The "name" attribute MUST be set when the
"type" attribute is "stat" or "custom". 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.
"level":
Defines the level of the event as either "warning" for a warning
event that needs action or "error" for an error event that requires
immediate action.
"exDate":
Contains the date and time that a "warning" level has or will
become an "error" level. At expiry, there MAY be a
connection failure or MAY be a login failure. An
example is an expired certification that will result in a connection
failure or an expired password that may result in a login
failure.
"value":
Identifies the value that resulted in the login security
event. An example is the negotiated insecure cipher suite or the
negotiated insecure TLS protocol.
"duration":
Defines the duration that a statistical event is associated
with, ending when the login command was received. The format of the
duration is defined by the duration primitive data type in Section
3.2.6 of .
"lang":
Identifies the negotiated language of the free-form description.
The format of the language is defined by the language primitive
data type in Section 3.3.3 of . The
default is "en" (English).
Example login security event for password expiration, where the
current date is 2020-03-25:
<loginSec:event
type="password"
level="warning"
exDate="2020-04-01T22:00:00.0Z"
lang="en">
Password expiration soon
</loginSec:event>
Example login security event for identifying 100 failed logins over
the last day, using the "stat" subtype of "failedLogins":
<loginSec:event
type="stat"
name="failedLogins"
level="warning"
value="100"
duration="P1D">
Excessive invalid daily logins
</loginSec:event>
"[LOGIN-SECURITY]" PasswordWhen the <pw>
element contains the predefined value of "[LOGIN-SECURITY]", the
<loginSec:pw> element overrides the <pw> element, which is
a constant value for the server to use the <loginSec:pw> element
for the password. Similarly, when the <newPw> element contains the predefined value
of "[LOGIN-SECURITY]", the <loginSec:newPw> element overrides
the <newPw> element, which is a constant value for the server to
use the <loginSec:newPW> element for the new password. The
"[LOGIN-SECURITY]" predefined string MUST be supported
by the server for the client to explicitly indicate to the server
whether to use <loginSec:pw> element in place of the <pw> element or to use the
<loginSec:newPW> in place of the <newPW> element. The server MUST NOT allow the client to set the password to the value
"[LOGIN-SECURITY]".Dates and TimesDate and time attribute values MUST be represented
in Universal Coordinated Time (UTC) using the Gregorian calendar. The
extended date-time form using upper case "T" and "Z" characters
defined in MUST be used to represent date-time
values, as XML Schema does not support truncated date-time forms or
lower case "T" and "Z" characters.EPP Command MappingA detailed description of the EPP syntax and semantics can be found
in the EPP core protocol specification .EPP <login> CommandThis extension defines additional elements to extend the EPP
<login> command and response to be used in conjunction with
.The EPP <login> command is used to establish a session with
an EPP server. This extension overrides the password that is passed
with the <pw> or the
<newPW> element, as defined in . A
<loginSec:loginSec> element is sent along with the <login> command and
MUST contain at least one of the following child
elements:
<loginSec:userAgent>:
OPTIONAL 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 MUST contain at
least one of the following child elements:
<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 format:
app = name SP version
name = 1*VCHAR
version = 1*VCHAR
<loginSec:tech>:
OPTIONAL 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
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.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 format:
os = arch SP name SP version
arch = 1*VCHAR
name = 1*VCHAR
version = 1*VCHAR
<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 (linefeed), #xD (carriage return), and #x20
(space) is replaced with a single #x20 (space). This element
MUST only be set if the <pw> element is set to the
"[LOGIN-SECURITY]" value.
<loginSec:newPW>:
OPTIONAL 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
MUST only be set if the <newPW> element is set to the
"[LOGIN-SECURITY]" value.
It is RECOMMENDED 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 is recommended in the absence of
other considerations.Example login command that uses the <loginSec:pw> element
instead of the <pw>
element () to establish the session and includes the
<loginSec:userAgent> element:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <login>
C: <clID>ClientX</clID>
C: <pw>[LOGIN-SECURITY]</pw>
C: <options>
C: <version>1.0</version>
C: <lang>en</lang>
C: </options>
C: <svcs>
C: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
C: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
C: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
C: <svcExtension>
C: <extURI>urn:ietf:params:xml:ns:epp:loginSec-1.0</extURI>
C: </svcExtension>
C: </svcs>
C: </login>
C: <extension>
C: <loginSec:loginSec
C: xmlns:loginSec=
C: "urn:ietf:params:xml:ns:epp:loginSec-1.0">
C: <loginSec:userAgent>
C: <loginSec:app>EPP SDK 1.0.0</loginSec:app>
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:userAgent>
C: <loginSec:pw>this is a long password</loginSec:pw>
C: </loginSec:loginSec>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example login command that uses the <loginSec:pw> element
instead of the <pw>
element () to
establish the session and that uses the <loginSec:newPW>
element instead of the
<newPW> element () to set the new password:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <login>
C: <clID>ClientX</clID>
C: <pw>[LOGIN-SECURITY]</pw>
C: <newPW>[LOGIN-SECURITY]</newPW>
C: <options>
C: <version>1.0</version>
C: <lang>en</lang>
C: </options>
C: <svcs>
C: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
C: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
C: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
C: <svcExtension>
C: <extURI>urn:ietf:params:xml:ns:epp:loginSec-1.0</extURI>
C: </svcExtension>
C: </svcs>
C: </login>
C: <extension>
C: <loginSec:loginSec
C: xmlns:loginSec=
C: "urn:ietf:params:xml:ns:epp:loginSec-1.0">
C: <loginSec:pw>this is a long password
C: </loginSec:pw>
C: <loginSec:newPW>new password that is still long
C: </loginSec:newPW>
C: </loginSec:loginSec>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Example login command that uses the <pw> element () to establish the session and
that uses the <loginSec:newPW> element instead of the <newPW> element () to set the
new password:
C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
C: <command>
C: <login>
C: <clID>ClientX</clID>
C: <pw>shortpassword</pw>
C: <newPW>[LOGIN-SECURITY]</newPW>
C: <options>
C: <version>1.0</version>
C: <lang>en</lang>
C: </options>
C: <svcs>
C: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
C: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
C: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
C: <svcExtension>
C: <extURI>urn:ietf:params:xml:ns:epp:loginSec-1.0</extURI>
C: </svcExtension>
C: </svcs>
C: </login>
C: <extension>
C: <loginSec:loginSec
C: xmlns:loginSec=
C: "urn:ietf:params:xml:ns:epp:loginSec-1.0">
C: <loginSec:newPW>new password that is still long
C: </loginSec:newPW>
C: </loginSec:loginSec>
C: </extension>
C: <clTRID>ABC-12345</clTRID>
C: </command>
C:</epp>
Upon a completed login command (success or failed), the extension
MUST be included in the response when both of the
following conditions hold:
Client supports extension:
The client supports the extension based on the
<svcExtension> element of the <login> command.
At least one login security event:
The server has identified at least one login security event to
communicate to the client.
The extension to the EPP response uses the
<loginSec:loginSecData> element that contains the following
child elements:
<loginSec:event>:
One or more <loginSec:event> elements defined in .
Example EPP response to a successful login command on 2020-03-25,
where the password will expire in a week:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <extension>
S: <loginSec:loginSecData
S: xmlns:loginSec=
S: "urn:ietf:params:xml:ns:epp:loginSec-1.0">
S: <loginSec:event
S: type="password"
S: level="warning"
S: exDate="2020-04-01T22:00:00.0Z"
S: lang="en">
S: Password expiring in a week
S: </loginSec:event>
S: </loginSec:loginSecData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
Example EPP response to a failed login command where the password
has expired and the new password does not meet the server complexity
requirements:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="2200">
S: <msg>Authentication error</msg>
S: </result>
S: <extension>
S: <loginSec:loginSecData
S: xmlns:loginSec=
S: "urn:ietf:params:xml:ns:epp:loginSec-1.0">
S: <loginSec:event
S: type="password"
S: level="error"
S: exDate="2020-03-24T22:00:00.0Z">
S: Password has expired
S: </loginSec:event>
S: <loginSec:event
S: type="newPW"
S: level="error">
S: New password does not meet complexity requirements
S: </loginSec:event>
S: </loginSec:loginSecData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
Example EPP response to a successful login command where
there is a set of login security events:
S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
S: <response>
S: <result code="1000">
S: <msg>Command completed successfully</msg>
S: </result>
S: <extension>
S: <loginSec:loginSecData
S: xmlns:loginSec=
S: "urn:ietf:params:xml:ns:epp:loginSec-1.0">
S: <loginSec:event
S: type="password"
S: level="warning"
S: exDate="2020-04-01T22:00:00.0Z"
S: lang="en">
S: Password expiration soon
S: </loginSec:event>
S: <loginSec:event
S: type="certificate"
S: level="warning"
S: exDate="2020-04-02T22:00:00.0Z"/>
S: <loginSec:event
S: type="cipher"
S: level="warning"
S: value="TLS_RSA_WITH_AES_128_CBC_SHA">
S: Non-PFS Cipher negotiated
S: </loginSec:event>
S: <loginSec:event
S: type="tlsProtocol"
S: level="warning"
S: value="TLSv1.0">
S: Insecure TLS protocol negotiated
S: </loginSec:event>
S: <loginSec:event
S: type="stat"
S: name="failedLogins"
S: level="warning"
S: value="100"
S: duration="P1D">
S: Excessive invalid daily logins
S: </loginSec:event>
S: <loginSec:event
S: type="custom"
S: name="myCustomEvent"
S: level="warning">
S: A custom login security event occurred
S: </loginSec:event>
S: </loginSec:loginSecData>
S: </extension>
S: <trID>
S: <clTRID>ABC-12345</clTRID>
S: <svTRID>54321-XYZ</svTRID>
S: </trID>
S: </response>
S:</epp>
Formal SyntaxThe EPP Login Security Extension schema is presented here.The formal
syntax shown here is a complete XML Schema representation of the object
mapping suitable for automated validation of EPP XML instances. The
<CODE BEGINS> and <CODE ENDS> tags are not part of the XML Schema; they are used to note the
beginning and ending of the XML Schema for URI registration purposes.Login Security Extension Schema
<?xml version="1.0" encoding="UTF-8"?>
<schema xmlns="http://www.w3.org/2001/XMLSchema"
xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
xmlns:loginSec="urn:ietf:params:xml:ns:epp:loginSec-1.0"
targetNamespace="urn:ietf:params:xml:ns:epp:loginSec-1.0"
elementFormDefault="qualified">
<!--
Import common element types.
-->
<import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />
<import namespace="urn:ietf:params:xml:ns:epp-1.0" />
<annotation>
<documentation>Extensible Provisioning Protocol v1.0
Login Security Extension Schema.</documentation>
</annotation>
<!-- Login command extension elements -->
<element name="loginSec" type="loginSec:loginSecType" />
<!--
Attributes associated with the login command extension.
-->
<complexType name="loginSecType">
<sequence>
<element name="userAgent"
type="loginSec:userAgentType" minOccurs="0" />
<element name="pw"
type="loginSec:pwType" minOccurs="0" />
<element name="newPW"
type="loginSec:pwType" minOccurs="0" />
</sequence>
</complexType>
<simpleType name="pwType">
<restriction base="token">
<minLength value="6" />
</restriction>
</simpleType>
<complexType name="userAgentType">
<choice>
<sequence>
<element name="app"
type="token" />
<element name="tech"
type="token" minOccurs="0" />
<element name="os"
type="token" minOccurs="0" />
</sequence>
<sequence>
<element name="tech"
type="token" />
<element name="os"
type="token" minOccurs="0" />
</sequence>
<element name="os"
type="token" />
</choice>
</complexType>
<!-- Login response extension elements -->
<element name="loginSecData"
type="loginSec:loginSecDataType" />
<complexType name="loginSecDataType">
<sequence>
<element name="event"
type="loginSec:eventType"
minOccurs="1" maxOccurs="unbounded" />
</sequence>
</complexType>
<!-- Security event element -->
<complexType name="eventType">
<simpleContent>
<extension base="normalizedString">
<attribute name="type"
type="loginSec:typeEnum" use="required" />
<attribute name="name"
type="token" />
<attribute name="level"
type="loginSec:levelEnum" use="required" />
<attribute name="exDate"
type="dateTime" />
<attribute name="value"
type="token" />
<attribute name="duration"
type="duration" />
<attribute name="lang"
type="language" default="en" />
</extension>
</simpleContent>
</complexType>
<!--
Enumerated list of event types, with extensibility via "custom".
-->
<simpleType name="typeEnum">
<restriction base="token">
<enumeration value="password" />
<enumeration value="certificate" />
<enumeration value="cipher" />
<enumeration value="tlsProtocol" />
<enumeration value="newPW" />
<enumeration value="stat" />
<enumeration value="custom" />
</restriction>
</simpleType>
<!--
Enumerated list of levels.
-->
<simpleType name="levelEnum">
<restriction base="token">
<enumeration value="warning" />
<enumeration value="error" />
</restriction>
</simpleType>
<!--
End of schema.
-->
</schema>
IANA ConsiderationsXML NamespaceThis document uses URNs to describe XML namespaces and XML schemas
conforming to a registry mechanism described in . The following URI assignment has been made by
IANA:Registration request for the loginSec namespace:
URI:
urn:ietf:params:xml:ns:epp:loginSec-1.0
Registrant Contact:
IESG
XML:
None. Namespace URIs do not represent an XML specification.
Registration request for the loginSec XML Schema:
URI:
urn:ietf:params:xml:schema:epp:loginSec-1.0
Registrant Contact:
IESG
XML:
See the "Formal Syntax" section of this document.
EPP Extension RegistryThe EPP extension described in this document has been registered
by IANA in the "Extensions for the Extensible Provisioning
Protocol (EPP)" registry described in . The details of the registration
are as follows:
Name of Extension:
"Login Security Extension for the Extensible
Provisioning Protocol (EPP)"
Document status:
Standards Track
Reference:
RFC 8807
Registrant Name and Email Address:
IESG, <iesg@ietf.org>
Top-Level Domains(TLDs):
Any
IPR Disclosure:
None
Status:
Active
Notes:
None
Security ConsiderationsThe security considerations of apply in this document, and this document enhances
these considerations.The extension leaves the password (<pw> element) and new
password (<newPW> element) minimum length greater than 6
characters and the maximum length up to server policy. The server
SHOULD enforce minimum and maximum length requirements
that are appropriate for their operating environment. One example of a
guideline for password length policies can be found in Section 5 of
NIST
Special Publication 800-63B.The client SHOULD NOT decrease
the security of a new password by decreasing the length of the current
password. For example, a client with a 20-character password set using
the extension should not use the login command in without using the extension to set
a new password that is less than or equal to 16 characters.The extension provides an extensible list of login security events to
inform clients of connection and login warnings and errors. The server
returning of security events to unauthenticated users needs to take into
account the security/privacy issues of returning information to
potential attackers.The user-agent information represents 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.ReferencesNormative ReferencesKey words for use in RFCs to Indicate Requirement LevelsIn many standards track documents several words are used to signify the requirements in the specification. These words are often capitalized. This document defines these words as they should be interpreted in IETF documents. This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements.The IETF XML RegistryThis document describes an IANA maintained registry for IETF standards which use Extensible Markup Language (XML) related items such as Namespaces, Document Type Declarations (DTDs), Schemas, and Resource Description Framework (RDF) Schemas.Augmented BNF for Syntax Specifications: ABNFInternet technical specifications often need to define a formal syntax. Over the years, a modified version of Backus-Naur Form (BNF), called Augmented BNF (ABNF), has been popular among many Internet specifications. The current specification documents ABNF. It balances compactness and simplicity with reasonable representational power. The differences between standard BNF and ABNF involve naming rules, repetition, alternatives, order-independence, and value ranges. This specification also supplies additional rule definitions and encoding for a core lexical analyzer of the type common to several Internet specifications. [STANDARDS-TRACK]Extensible Provisioning Protocol (EPP)This document describes an application-layer client-server protocol for the provisioning and management of objects stored in a shared central repository. Specified in XML, the protocol defines generic object management operations and an extensible framework that maps protocol operations to objects. This document includes a protocol specification, an object mapping template, and an XML media type registration. This document obsoletes RFC 4930. [STANDARDS-TRACK]Ambiguity of Uppercase vs Lowercase in RFC 2119 Key WordsRFC 2119 specifies common key words that may be used in protocol specifications. This document aims to reduce the ambiguity by clarifying that only UPPERCASE usage of the key words have the defined special meanings.XML Schema Part 2: Datatypes Second EditionInformative ReferencesExtension Registry for the Extensible Provisioning ProtocolThe Extensible Provisioning Protocol (EPP) includes features to add functionality by extending the protocol. It does not, however, describe how those extensions are managed. This document describes a procedure for the registration and management of extensions to EPP, and it specifies a format for an IANA registry to record those extensions.Preparation, Enforcement, and Comparison of Internationalized Strings Representing Usernames and PasswordsThis document describes updated methods for handling Unicode strings representing usernames and passwords. The previous approach was known as SASLprep (RFC 4013) and was based on Stringprep (RFC 3454). The methods specified in this document provide a more sustainable approach to the handling of internationalized usernames and passwords. This document obsoletes RFC 7613.AcknowledgementsThe authors wish to thank the following persons for their feedback
and suggestions: , , ,
, and .Authors' AddressesVeriSign, Inc.12061 Bluemont WayRestonVA20190United States of Americajgould@verisign.comhttp://www.verisign.comVeriSign, Inc.12061 Bluemont WayRestonVA20190United States of Americampozun@verisign.comhttp://www.verisign.com