RFC 8807

Login Security Extension for the Extensible Provisioning Protocol (EPP)

📅 published August 2020, from ietf

Login Security Extension for the Extensible Provisioning Protocol (EPP) 💖

okay bestie, let's get into it! 🎀 This doc is RFC 8807, written by J. Gould and M. Pozun (both from VeriSign, Inc.) and published in August 2020. It's a Standards Track doc 🦋, which means it's an official Internet standard, not just a suggestion. It comes from the ISSN 2070-1721 series. It doesn't obsolete or update any other RFCs, so it's a fresh start, no drama 💅.

The vibe: EPP has a login command, and its password can only be 16 characters long 😭. This extension lets you use longer passwords and passphrases, and adds extra security info to the login response. Let's go! ✨

This is part 1 of 4, so more is coming, don't go anywhere 🫶

Abstract

The Extensible Provisioning Protocol (EPP) includes a client authentication scheme based on a user identifier and password 🔐. The password field's structure is defined by an XML Schema data type that sets minimum and maximum password length values, but there's no other password management support beyond changing the password 🙈. This document describes an EPP extension that lets you create longer passwords and adds extra 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, received public review, and was approved for publication by the Internet Engineering Steering Group (IESG). If you want more info about Internet Standards, check out Section 2 of RFC 7841 🧚.

For info on the current status of this document, any errata, and how to give feedback, go to https://www.rfc-editor.org/info/rfc8807 🎀.

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 (https://trustee.ietf.org/license-info) in effect on the date of publication. Please read these carefully, because they describe your rights and restrictions for 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 they're provided without warranty as described in the Simplified BSD License 💅.

Table of Contents

1.  Introduction
  1.1.  Conventions Used in This Document
2.  Migrating to Newer Versions of This Extension
3.  Object Attributes
  3.1.  Event
  3.2.  "[LOGIN-SECURITY]" Password
  3.3.  Dates and Times
4.  EPP Command Mapping
  4.1.  EPP <login> Command
5.  Formal Syntax
  5.1.  Login Security Extension Schema
6.  IANA Considerations
  6.1.  XML Namespace
  6.2.  EPP Extension Registry
7.  Security Considerations
8.  References
  8.1.  Normative References
  8.2.  Informative References
Acknowledgements
Authors' Addresses

1. Introduction ✨

okay so this doc is an EPP extension that makes login more secure 🔒. EPP already has a login command defined in [RFC5730], and it caps passwords at 16 characters 😤. That's a problem because it makes stronger, higher-entropy password policies basically impossible 💀.

This extension fixes that. It lets you use longer passwords (or passphrases) past the 16-character max 🔥, and it adds a list of security events to the login response. The password (current and new) from EPP [RFC5730] can be overridden by the password in this extension so it can go past 16 characters 💖.

The security events it supports are: password expiry, client certificate expiry, insecure cipher, insecure TLS protocol, new password complexity, login security statistical warning, and a custom event 🧚. Each event can have an identified event type or subtype, a security level of warning or error, a future or past-due expiration date, the value that caused the event, the duration of a statistical event, and a free-form description with an optional language 🌸.

1.1. Conventions Used in This Document

Ok 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 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 📚.

XML is case sensitive 🙈. Unless stated otherwise, XML specifications and examples in this document MUST be interpreted in the character case presented, so you can build a conforming implementation 💅.

In examples, "C:" represents lines sent by a protocol client and "S:" represents lines returned by a protocol server 🦋. Indentation and whitespace in examples are only there to show how elements relate. They aren't a required feature of this protocol ✨.

"loginSec-1.0" is short 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, use a proper namespace-aware XML parser and serializer to interpret and output XML documents 🫶.

"whitespace" is defined by the XML Schema whiteSpace data type in [W3C.REC-xmlschema-2-20041028]. It only includes these ASCII whitespace characters:

#x9 (tab), #xA (linefeed), #xD (carriage return), and #x20 (space)

2. Migrating to Newer Versions of This Extension 🌈

Servers that implement this extension SHOULD provide a way for clients to update their implementations gradually when a new version of the extension is deployed 💜. A newer version is expected to use an XML namespace with a higher version number than the older ones 🧚.

Servers SHOULD (for a temporary migration period, up to server policy) keep supporting older versions of the extension alongside the newest one, and let clients pick their preferred version through the <svcExtension> element of the <login> command 🦋.

If a client requests multiple versions of the extension at login, then when the server prepares responses to commands that don't include extension elements, it SHOULD only include extension elements in the namespace of the newest version the client requested 🔥.

When the server prepares responses to commands that do include extension elements, it SHOULD only include extension elements for the extension versions present in the command 💅.

3. Object Attributes ⭐

This extension adds new elements to the [RFC5730] login command and response. Only those new elements are described here 🌸.

3.1. Event 🔐

A security event using the <loginSec:event> element represents either a warning or an error that the server spots after the client has connected and sent the login command 👀. The <loginSec:event> element sits in a list of one or more elements inside the <loginSec:loginSecData> element, so there MAY be multiple events returned to help the client address them 🫶. The <loginSec:event> MAY include a free-form description 💖. All of the security events use a consistent set of attributes, and the exact set that applies depends on the event type 🎀.

The supported <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 already 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. This name is free-form and isn't expected to be parsed and automatically handled 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 (https://www.iana.org/assignments/tls-parameters/tls-parameters.xhtml#tls-parameters-4) 🧚. "tlsProtocol": Identifies the use of an insecure or deprecated TLS protocol. The "name" attribute MUST be set with the name of the TLS protocol. This name is free-form and isn't expected to be parsed and automatically handled by the client 🙈. "newPW": The new password doesn't meet the server's password complexity requirements 😤. "stat": Provides a login security statistical warning. It MUST set the "name" attribute to the name of the statistic subtype 📊. "custom": A custom event type. It 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 or negotiated out of band to EPP, or by using a separate EPP extension designed to give the client server policy information 🦋.

"level": Defines the level of the event as either "warning" (a warning event that needs action) or "error" (an error event that requires immediate action) 🔥.

"exDate": Contains the date and time that a "warning" level has become or will become an "error" level. At expiry, there MAY be a connection failure or MAY be a login failure. For example, an expired certificate will result in a connection failure, or an expired password may result in a login failure 💀.

"value": Identifies the value that resulted in the login security event. For example, the negotiated insecure cipher suite or the negotiated insecure TLS protocol 🌸.

"duration": Defines the duration 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 [W3C.REC-xmlschema-2-20041028] ⏱️.

"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 [W3C.REC-xmlschema-2-20041028]. The default is "en" (English) 🌍.

Here's an 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>

And here's an 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>

That's the end of part 1! 🎀 Part 2 is coming next, where we get into the password section, dates and times, EPP command mapping and the formal syntax. Stay tuned, bestie 🦋✨

3.2. "[LOGIN-SECURITY]" Password

okay so this is the magic word moment 🪄 When the <pw> element from [RFC5730] holds the predefined value "[LOGIN-SECURITY]", the <loginSec:pw> element overrides it, so the server knows to use <loginSec:pw> as the password instead. Same deal for <newPw>: if it's set to "[LOGIN-SECURITY]", the <loginSec:newPw> element overrides it, and the server uses the <loginSec:newPW> element for the new password. 💅 The "[LOGIN-SECURITY]" predefined string MUST be supported by the server, so the client can explicitly say whether to use <loginSec:pw> in place of <pw> or <loginSec:newPW> in place of <newPW>. And the server MUST NOT allow anyone to set the password to the value "[LOGIN-SECURITY]". that would be a total mess 💀

3.3. Dates and Times

🕰️ Date and time attribute values MUST be represented in Universal Coordinated Time (UTC) using the Gregorian calendar. The extended date-time form with upper case "T" and "Z" characters, defined in [W3C.REC-xmlschema-2-20041028], MUST be used for date-time values, because XML Schema doesn't support truncated date-time forms or lower case "T" and "Z" characters. no shortcuts, bestie 🫶

4. EPP Command Mapping

✨ If you want the full tea on EPP syntax and semantics, go read the EPP core protocol spec in [RFC5730]. this part is the extension's add-ons 🎀

4.1. EPP <login> Command

okay so this extension adds extra elements to the EPP <login> command and its response, and it works alongside [RFC5730] 🦋 The EPP <login> command is how a client starts a session with an EPP server. This extension overrides the password passed in the [RFC5730] <pw> or <newPW> element, as covered in Section 3.2. A <loginSec:loginSec> element goes along with the [RFC5730] <login> command, and it 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. The server uses it to spot functional or security constraints, current security issues, and potential future ones for the client. The server may use the info for real-time identification and client notification of security issues, like keying off the client application software to run security rule checks. The server may also capture the info to spot future security policy issues, like 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> value can be made by appending the version number to the application software's name, using the Augmented Backus-Naur Form (ABNF) grammar [RFC5234] 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> value can be made by including the technology vendor, technology name, and technology version, using the Augmented Backus-Naur Form (ABNF) grammar [RFC5234] format:
tech = vendor SP name SP version
vendor = 1*VCHAR
name = 1*VCHAR
version = 1*VCHAR
  • <loginSec:os>: OPTIONAL client operating system used, with version if available, such as "x86_64 Mac OS X 10.15.2". The <loginSec:os> value can be made by including the operating system architecture, operating system name, and operating system version, using the Augmented Backus-Naur Form (ABNF) grammar [RFC5234] 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 set by server policy. All leading and trailing whitespace is removed, and all internal contiguous whitespace (including #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 [RFC5730] <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 set by server policy. All leading and trailing whitespace is removed, and all internal contiguous whitespace (including #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 [RFC5730] <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) through #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 [RFC8265] is recommended in the absence of other considerations.

Here's an example login command that uses the <loginSec:pw> element instead of the <pw> element ([RFC5730]) 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>

And here's an example login command that uses the <loginSec:pw> element instead of the <pw> element ([RFC5730]) to establish the session, and uses the <loginSec:newPW> element instead of the <newPW> element ([RFC5730]) 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>

And one more: a login command that uses the <pw> element ([RFC5730]) to establish the session, and uses the <loginSec:newPW> element instead of the <newPW> element ([RFC5730]) 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 tell the client about.

The extension to the EPP response uses the <loginSec:loginSecData> element, which contains the following child element:

  • <loginSec:event>: One or more <loginSec:event> elements defined in Section 3.1.

Here's an 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:

Okay bestie, the example that starts this part is a failed login 🙈 The server replies with code 2200 and tells you the password expired, and the new one didn't pass the complexity check 💀

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>

Now for the glow-up version 🦋 This is a successful login (1000) that still comes back with a whole bunch of login security events, so the client gets all the tea ✨

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>

5. Formal Syntax 🎀

This is where the XML Schema lives, and it's the real deal. It's a complete representation of the object mapping, so you can use it to run automated validation on EPP XML instances 🤖💜

The <CODE BEGINS> and <CODE ENDS> tags aren't part of the schema itself. They just mark where the XML Schema starts and ends for URI registration purposes 📌

5.1. Login Security Extension Schema 🌈

<CODE BEGINS>
<?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>
<CODE ENDS>

6. IANA Considerations 🦋

6.1. XML Namespace 💖

This doc uses URNs to describe XML namespaces and XML schemas, following the registry mechanism from [RFC3688]. IANA has already made the following URI assignments 🎉

Here's the 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.

And here's the 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.

6.2. EPP Extension Registry 🌸

IANA has registered this EPP extension in the "Extensions for the Extensible Provisioning Protocol (EPP)" registry, which is described in [RFC7451]. Here are the deets 👀

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

7. Security Considerations 🔐💀

Bestie, this section is serious. Read every word 🚨

The security stuff from [RFC5730] applies to this document too, and this document levels those considerations up 💅

The extension keeps the password (<pw> element) and new password (<newPW> element) minimum length greater than 6 characters, and leaves the maximum length up to server policy. The server SHOULD enforce minimum and maximum length requirements that are appropriate for their operating environment ✨ If you want one example of a guideline for password length policies, check out Section 5 of NIST Special Publication 800-63B (https://pages.nist.gov/800-63-3/sp800-63b.html) 📖

The client SHOULD NOT decrease the security of a new password by decreasing the length of the current password. Like, if a client has a 20-character password set using the extension, it should not use the login command in [RFC5730] without using the extension to set a new password that is less than or equal to 16 characters. Don't downgrade yourself, babe 🙅‍♀️

The extension gives you an extensible list of login security events so clients can be warned about connection and login problems, both warnings and errors ⚠️ When the server returns security events to unauthenticated users, it needs to consider the security and privacy issues of handing information to potential attackers 👀🕵️‍♀️

The user-agent information describes the client system in a system-to-system interface, so the user-agent information MUST NOT provide any ability to track individual users or classes of users 🙅‍♀️🫶 No stalking, period 💀

8. References 📚

8.1. Normative References 💜

[RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
           Requirement Levels", BCP 14, RFC 2119,
           DOI 10.17487/RFC2119, March 1997,
           <https://www.rfc-editor.org/info/rfc2119>.

[RFC3688]  Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
           DOI 10.17487/RFC3688, January 2004,
           <https://www.rfc-editor.org/info/rfc3688>.

[RFC5234]  Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
           Specifications: ABNF", STD 68, RFC 5234,
           DOI 10.17487/RFC5234, January 2008,
           <https://www.rfc-editor.org/info/rfc5234>.

[RFC5730]  Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
           STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
           <https://www.rfc-editor.org/info/rfc5730>.

[RFC8174]  Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
           2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
           May 2017, <https://www.rfc-editor.org/info/rfc8174>.

[W3C.REC-xmlschema-2-20041028]
           Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
           Second Edition", W3C Recommendation REC-xmlschema-
           2-20041028, October 2004,
           <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.

8.2. Informative References 🌷

[RFC7451]  Hollenbeck, S., "Extension Registry for the Extensible
           Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
           February 2015, <https://www.rfc-editor.org/info/rfc7451>.

[RFC8265]  Saint-Andre, P. and A. Melnikov, "Preparation,
           Enforcement, and Comparison of Internationalized Strings
           Representing Usernames and Passwords", RFC 8265,
           DOI 10.17487/RFC8265, October 2017,
           <https://www.rfc-editor.org/info/rfc8265>.

Acknowledgements 🫶

The authors want to give a big thank you to these lovely people for their feedback and suggestions: Martin Casanova, Scott Hollenbeck, Barry Leiba, Patrick Mevzek, and Joseph Yee 💖✨

Authors' Addresses ✨

okay bestie, last stop! 🧚 This is where we meet the two people who wrote the whole thing. Their contact info is right here, so if you have questions about the protocol, these are your people 💅

James Gould is first 💜 Here's where to find him:

James Gould
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America

Email: jgould@verisign.com
URI:   http://www.verisign.com

And then there's Matthew Pozun, who helped write it too 🎀 His details are:

Matthew Pozun
VeriSign, Inc.
12061 Bluemont Way
Reston, VA 20190
United States of America

Email: mpozun@verisign.com
URI:   http://www.verisign.com

Both of them work at VeriSign, Inc. in Reston, Virginia, so that's the place to look if you want to reach out 🌸 The end, periodt 🦋✨

📦 where this page comes from