Login Security Extension for the Extensible Provisioning Protocol (EPP)
Extracted elements (24)
A newer version of the extension is expected to use an XML namespace with a higher version number (e.g., loginSec-2.0) rather than in-place schema changes, enabling parallel version support and client-controlled migration via <svcExtension>.
The "[LOGIN-SECURITY]" sentinel value in the RFC 5730 <pw>/<newPW> elements was chosen as the indirection mechanism so that the extension can override the password without breaking backward compatibility with the base EPP XML schema, which still requires a conforming <pw> value.
The base RFC 5730 password length is limited to 16 characters. This extension overrides it by using the "[LOGIN-SECURITY]" sentinel in the base <pw>/<newPW> fields, enabling passwords of arbitrary length (minimum 6 characters, maximum per server policy) via <loginSec:pw> and <loginSec:newPW>.
When a client requests multiple versions of the loginSec extension at login, the server SHOULD respond using only the namespace of the newest requested version for commands that do not include extension elements, and use the version present in the command for commands that do include extension elements.
Date and time attribute values MUST be represented in UTC using the Gregorian calendar, using the extended date-time form with upper case "T" and "Z" characters as defined in the XML Schema specification.
Implementations MUST NOT depend on the "loginSec" XML namespace prefix; instead they MUST employ a proper namespace-aware XML parser and serializer.
<loginSec:pw> MUST only be set if the RFC 5730 <pw> element is set to the "[LOGIN-SECURITY]" value; similarly, <loginSec:newPW> MUST only be set if the RFC 5730 <newPW> element is set to "[LOGIN-SECURITY]".
Plain text passwords in <loginSec:pw> and <loginSec:newPW> are RECOMMENDED to use printable ASCII characters #x20–#x7E with high entropy such as 128 bits. If non-ASCII characters are supported, use of the OpaqueString PRECIS profile (RFC 8265) is recommended.
Servers SHOULD enforce minimum and maximum password length requirements appropriate for their operating environment, referencing NIST SP 800-63B Section 5 as one example guideline.
Servers SHOULD provide support for older versions of the extension in parallel to the newest version during a migration period (up to server policy), and SHOULD only include extension elements in the namespace of the newest version requested when responding to commands without extension elements.
The login security extension MUST be included in the EPP response when (1) the client supports the extension via <svcExtension> and (2) the server has identified at least one login security event to communicate. Both conditions must hold.
The "[LOGIN-SECURITY]" predefined string MUST be supported by the server to allow clients to explicitly indicate whether to use the <loginSec:pw> element in place of the RFC 5730 <pw> element, or <loginSec:newPW> in place of <newPW>. The server MUST NOT allow the client to set the password to the value "[LOGIN-SECURITY]".
The "name" attribute MUST be set on a <loginSec:event> when the "type" attribute is "stat" or "custom". For type "cipher", "name" MUST be set with the cipher suite name; for "tlsProtocol", "name" MUST be set with the TLS protocol name.
The user-agent information represents a system-to-system interface, so the user-agent information MUST NOT provide any ability to track individual users or classes of users.
The <loginSec:event> element represents a security warning or error identified by the server after the client submits the login command. Required attributes are "type" (enumerated: password, certificate, cipher, tlsProtocol, newPW, stat, custom) and "level" (warning or error). Optional attributes include "name", "exDate", "value", "duration", and "lang".
The <loginSec:loginSec> element extends the EPP <login> command and MUST contain at least one of: <loginSec:userAgent> (optional client app/tech/OS info), <loginSec:pw> (extended password), or <loginSec:newPW> (extended new password).
The <loginSec:loginSecData> element extends the EPP login response and contains one or more <loginSec:event> child elements conveying security events back to the client.
The <loginSec:userAgent> element identifies the client application software, technology, and OS. It MUST contain at least one of: <loginSec:app> (application name and version), <loginSec:tech> (vendor, technology name, version), or <loginSec:os> (architecture, OS name, version).
RFC 8807 registers the "Login Security Extension for the Extensible Provisioning Protocol (EPP)" in the IANA "Extensions for the Extensible Provisioning Protocol (EPP)" registry (RFC 7451), with status Active and applicability to any TLD.
RFC 8807 registers the XML namespace URI "urn:ietf:params:xml:ns:epp:loginSec-1.0" and the XML Schema URI "urn:ietf:params:xml:schema:epp:loginSec-1.0" in the IETF XML Registry (RFC 3688), with IESG as registrant.
A client SHOULD NOT decrease the security of a new password by reducing its length. For example, a client with a 20-character password set via the extension should not switch to the base RFC 5730 login command to set a new password of 16 characters or fewer.
The server returning login security events (e.g., password expiry, failed login statistics) to unauthenticated users must weigh the security and privacy risks of disclosing that information to potential attackers.
The eventType XML Schema complex type uses simpleContent extending normalizedString, with required attributes "type" (typeEnum) and "level" (levelEnum), and optional attributes "name" (token), "exDate" (dateTime), "value" (token), "duration" (duration), and "lang" (language, default "en").
The <loginSec:pw> and <loginSec:newPW> fields use the "pwType" XML Schema simple type, a token with a minimum length of 6 characters and no maximum length in the schema (maximum is up to server policy). Whitespace normalization removes leading/trailing whitespace and collapses internal whitespace to a single space (#x20).