1 Internet Engineering Task Force (IETF) J. Gould
2 Request for Comments: 8807 M. Pozun
3 Category: Standards Track VeriSign, Inc.
4 ISSN: 2070-1721 August 2020
5
6
7 Login Security Extension for the Extensible Provisioning Protocol (EPP)
8
9 Abstract
10
11 The Extensible Provisioning Protocol (EPP) includes a client
12 authentication scheme that is based on a user identifier and
13 password. The structure of the password field is defined by an XML
14 Schema data type that specifies minimum and maximum password length
15 values, but there are no other provisions for password management
16 other than changing the password. This document describes an EPP
17 extension that allows longer passwords to be created and adds
18 additional security features to the EPP login command and response.
19
20 Status of This Memo
21
22 This is an Internet Standards Track document.
23
24 This document is a product of the Internet Engineering Task Force
25 (IETF). It represents the consensus of the IETF community. It has
26 received public review and has been approved for publication by the
27 Internet Engineering Steering Group (IESG). Further information on
28 Internet Standards is available in Section 2 of RFC 7841.
29
30 Information about the current status of this document, any errata,
31 and how to provide feedback on it may be obtained at
32 https://www.rfc-editor.org/info/rfc8807.
33
34 Copyright Notice
35
36 Copyright (c) 2020 IETF Trust and the persons identified as the
37 document authors. All rights reserved.
38
39 This document is subject to BCP 78 and the IETF Trust's Legal
40 Provisions Relating to IETF Documents
41 (https://trustee.ietf.org/license-info) in effect on the date of
42 publication of this document. Please review these documents
43 carefully, as they describe your rights and restrictions with respect
44 to this document. Code Components extracted from this document must
45 include Simplified BSD License text as described in Section 4.e of
46 the Trust Legal Provisions and are provided without warranty as
47 described in the Simplified BSD License.
48
49 Table of Contents
50
51 1. Introduction
52 1.1. Conventions Used in This Document
53 2. Migrating to Newer Versions of This Extension
54 3. Object Attributes
55 3.1. Event
56 3.2. "[LOGIN-SECURITY]" Password
57 3.3. Dates and Times
58 4. EPP Command Mapping
59 4.1. EPP <login> Command
60 5. Formal Syntax
61 5.1. Login Security Extension Schema
62 6. IANA Considerations
63 6.1. XML Namespace
64 6.2. EPP Extension Registry
65 7. Security Considerations
66 8. References
67 8.1. Normative References
68 8.2. Informative References
69 Acknowledgements
70 Authors' Addresses
71
72 1. Introduction
73
74 This document describes an Extensible Provisioning Protocol (EPP)
75 extension for enhancing the security of the EPP login command in EPP
76 [RFC5730]. EPP [RFC5730] includes a maximum password length of 16
77 characters, which inhibits implementing stronger password security
78 policies with higher entropy. The enhancements include supporting
79 longer passwords (or passphrases) than the 16-character maximum and
80 providing a list of security events in the login response. The
81 password (current and new) in EPP [RFC5730] can be overridden by the
82 password included in the extension to extend past the 16-character
83 maximum. The security events supported include password expiry,
84 client certificate expiry, insecure cipher, insecure TLS protocol,
85 new password complexity, login security statistical warning, and a
86 custom event. The attributes supported by the security events
87 include an identified event type or a subtype, an indicated security
88 level of warning or error, a future or past-due expiration date, the
89 value that resulted in the event, the duration of the statistical
90 event, and a free-form description with an optional language.
91
92 1.1. Conventions Used in This Document
93
94 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
95 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
96 "OPTIONAL" in this document are to be interpreted as described in
97 BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all
98 capitals, as shown here.
99
100 XML is case sensitive. Unless stated otherwise, XML specifications
101 and examples provided in this document MUST be interpreted in the
102 character case presented in order to develop a conforming
103 implementation.
104
105 In examples, "C:" represents lines sent by a protocol client and "S:"
106 represents lines returned by a protocol server. In examples,
107 indentation and whitespace are provided only to illustrate element
108 relationships and are not a required feature of this protocol.
109
110 "loginSec-1.0" is used as an abbreviation for
111 "urn:ietf:params:xml:ns:epp:loginSec-1.0". The XML namespace prefix
112 "loginSec" is used, but implementations MUST NOT depend on it.
113 Instead, they are to employ a proper namespace-aware XML parser and
114 serializer to interpret and output the XML documents.
115
116 "whitespace" is defined by the XML Schema whiteSpace data type in
117 [W3C.REC-xmlschema-2-20041028], which only includes the ASCII
118 whitespace characters #x9 (tab), #xA (linefeed), #xD (carriage
119 return), and #x20 (space).
120
121 2. Migrating to Newer Versions of This Extension
122
123 Servers that implement this extension SHOULD provide a way for
124 clients to progressively update their implementations when a new
125 version of the extension is deployed. A newer version of the
126 extension is expected to use an XML namespace with a higher version
127 number than the prior versions.
128
129 Servers SHOULD (for a temporary migration period up to server policy)
130 provide support for older versions of the extension in parallel to
131 the newest version and allow clients to select their preferred
132 version via the <svcExtension> element of the <login> command.
133
134 If a client requests multiple versions of the extension at login,
135 then, when preparing responses to commands that do not include
136 extension elements, the server SHOULD only include extension elements
137 in the namespace of the newest version of the extension requested by
138 the client.
139
140 When preparing responses to commands that do include extension
141 elements, the server SHOULD only include extension elements for the
142 extension versions present in the command.
143
144 3. Object Attributes
145
146 This extension adds additional elements to [RFC5730] login command
147 and response. Only those new elements are described here.
148
149 3.1. Event
150
151 A security event using the <loginSec:event> element represents either
152 a warning or error identified by the server after the client has
153 connected and submitted the login command. The <loginSec:event>
154 element is contained in a list of one or more elements in the
155 <loginSec:loginSecData> element, so there MAY be multiple events
156 returned that provide information for the client to address. The
157 <loginSec:event> MAY include a free-form description. All of the
158 security events use a consistent set of attributes, where the exact
159 set of applicable attributes is based on the event type. The
160 supported set of <loginSec:event> element attributes include:
161
162 "type": A REQUIRED attribute that defines the type of security
163 event. The enumerated list of "type" values includes:
164
165 "password": Identifies a password expiry event where the
166 password expires in the future or has expired based on the
167 "exDate" date and time. The "exDate" attribute MUST be set
168 with the password expiry date and time.
169
170 "certificate": Identifies a client certificate expiry event
171 where the client certificate will expire at the "exDate" date
172 and time. The "exDate" attribute MUST be set with the
173 certificate expiry date and time.
174
175 "cipher": Identifies the use of an insecure or deprecated TLS
176 cipher suite. The "name" attribute MUST be set with the name
177 of the cipher suite, which is free-form and is not expected
178 to be parsed and automatically addressed by the client. An
179 example of cipher suite names can be found in the TLS Cipher
180 Suites of the "Transport Layer Security (TLS) Parameters"
181 registry (https://www.iana.org/assignments/tls-parameters/
182 tls-parameters.xhtml#tls-parameters-4).
183
184 "tlsProtocol": Identifies the use of an insecure or deprecated
185 TLS protocol. The "name" attribute MUST be set with the name
186 of the TLS protocol, which is free-form and is not expected
187 to be parsed and automatically addressed by the client.
188
189 "newPW": The new password does not meet the server password
190 complexity requirements.
191
192 "stat": Provides a login security statistical warning that MUST
193 set the "name" attribute to the name of the statistic
194 subtype.
195
196 "custom": Custom event type that MUST set the "name" attribute
197 with the custom event type name.
198
199 "name": Used to define a subtype when the "type" attribute is not
200 "custom" or the full type name when the "type" attribute is
201 "custom". The "name" attribute MUST be set when the "type"
202 attribute is "stat" or "custom". The possible set of "name"
203 values, by event type, can be discovered/negotiated out of band
204 to EPP or using a separate EPP extension designed to provide
205 server policy information to the client.
206
207 "level": Defines the level of the event as either "warning" for a
208 warning event that needs action or "error" for an error event
209 that requires immediate action.
210
211 "exDate": Contains the date and time that a "warning" level has or
212 will become an "error" level. At expiry, there MAY be a
213 connection failure or MAY be a login failure. An example is an
214 expired certification that will result in a connection failure or
215 an expired password that may result in a login failure.
216
217 "value": Identifies the value that resulted in the login security
218 event. An example is the negotiated insecure cipher suite or the
219 negotiated insecure TLS protocol.
220
221 "duration": Defines the duration that a statistical event is
222 associated with, ending when the login command was received. The
223 format of the duration is defined by the duration primitive data
224 type in Section 3.2.6 of [W3C.REC-xmlschema-2-20041028].
225
226 "lang": Identifies the negotiated language of the free-form
227 description. The format of the language is defined by the
228 language primitive data type in Section 3.3.3 of
229 [W3C.REC-xmlschema-2-20041028]. The default is "en" (English).
230
231 Example login security event for password expiration, where the
232 current date is 2020-03-25:
233
234 <loginSec:event
235 type="password"
236 level="warning"
237 exDate="2020-04-01T22:00:00.0Z"
238 lang="en">
239 Password expiration soon
240 </loginSec:event>
241
242 Example login security event for identifying 100 failed logins over
243 the last day, using the "stat" subtype of "failedLogins":
244
245 <loginSec:event
246 type="stat"
247 name="failedLogins"
248 level="warning"
249 value="100"
250 duration="P1D">
251 Excessive invalid daily logins
252 </loginSec:event>
253
254 3.2. "[LOGIN-SECURITY]" Password
255
256 When the [RFC5730] <pw> element contains the predefined value of
257 "[LOGIN-SECURITY]", the <loginSec:pw> element overrides the <pw>
258 element, which is a constant value for the server to use the
259 <loginSec:pw> element for the password. Similarly, when the
260 [RFC5730] <newPw> element contains the predefined value of "[LOGIN-
261 SECURITY]", the <loginSec:newPw> element overrides the <newPw>
262 element, which is a constant value for the server to use the
263 <loginSec:newPW> element for the new password. The "[LOGIN-
264 SECURITY]" predefined string MUST be supported by the server for the
265 client to explicitly indicate to the server whether to use
266 <loginSec:pw> element in place of the [RFC5730] <pw> element or to
267 use the <loginSec:newPW> in place of the [RFC5730] <newPW> element.
268 The server MUST NOT allow the client to set the password to the value
269 "[LOGIN-SECURITY]".
270
271 3.3. Dates and Times
272
273 Date and time attribute values MUST be represented in Universal
274 Coordinated Time (UTC) using the Gregorian calendar. The extended
275 date-time form using upper case "T" and "Z" characters defined in
276 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time
277 values, as XML Schema does not support truncated date-time forms or
278 lower case "T" and "Z" characters.
279
280 4. EPP Command Mapping
281
282 A detailed description of the EPP syntax and semantics can be found
283 in the EPP core protocol specification [RFC5730].
284
285 4.1. EPP <login> Command
286
287 This extension defines additional elements to extend the EPP <login>
288 command and response to be used in conjunction with [RFC5730].
289
290 The EPP <login> command is used to establish a session with an EPP
291 server. This extension overrides the password that is passed with
292 the [RFC5730] <pw> or the <newPW> element, as defined in Section 3.2.
293 A <loginSec:loginSec> element is sent along with the [RFC5730]
294 <login> command and MUST contain at least one of the following child
295 elements:
296
297 <loginSec:userAgent>: OPTIONAL client user-agent information that
298 identifies the client application software, technology, and
299 operating system used by the server to identify functional or
300 security constraints, current security issues, and potential
301 future functional or security issues for the client. The server
302 may use the information for real-time identification and client
303 notification of security issues, such as keying off of the client
304 application software for executing security rule checks. The
305 server may capture the information to identify future security
306 policy issues, such as deprecating or removing TLS cipher suites
307 or TLS protocols. The <loginSec:userAgent> element MUST contain
308 at least one of the following child elements:
309
310 <loginSec:app>: OPTIONAL name of the client application software
311 with version if available, such as the name of the client SDK
312 "EPP SDK 1.0.0". The <loginSec:app> element value can be
313 created by appending the version number to the name of the
314 application software, such as the Augmented Backus-Naur Form
315 (ABNF) grammar [RFC5234] format:
316
317 app = name SP version
318 name = 1*VCHAR
319 version = 1*VCHAR
320
321 <loginSec:tech>: OPTIONAL technology used for the client
322 software with version if available, such as "Vendor Java
323 11.0.6". The <loginSec:tech> element value can be created by
324 including the technology vendor, technology name, and
325 technology version, such as the Augmented Backus-Naur Form
326 (ABNF) grammar [RFC5234] format:
327
328 tech = vendor SP name SP version
329 vendor = 1*VCHAR
330 name = 1*VCHAR
331 version = 1*VCHAR
332
333 <loginSec:os>: OPTIONAL client operating system used with
334 version if available, such as "x86_64 Mac OS X 10.15.2". The
335 <loginSec:os> element value can be created by including the
336 operating system architecture, operating system name, and
337 operating system version, such as the Augmented Backus-Naur
338 Form (ABNF) grammar [RFC5234] format:
339
340 os = arch SP name SP version
341 arch = 1*VCHAR
342 name = 1*VCHAR
343 version = 1*VCHAR
344
345 <loginSec:pw>: OPTIONAL plain text password that is case sensitive,
346 has a minimum length of 6 characters, and has a maximum length
347 that is up to server policy. All leading and trailing whitespace
348 is removed, and all internal contiguous whitespace that includes
349 #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20
350 (space) is replaced with a single #x20 (space). This element
351 MUST only be set if the [RFC5730] <pw> element is set to the
352 "[LOGIN-SECURITY]" value.
353
354 <loginSec:newPW>: OPTIONAL plain text new password that is case
355 sensitive, has a minimum length of 6 characters, and has a
356 maximum length that is up to server policy. All leading and
357 trailing whitespace is removed, and all internal contiguous
358 whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage
359 return), and #x20 (space) is replaced with a single #x20 (space).
360 This element MUST only be set if the [RFC5730] <newPW> element is
361 set to the "[LOGIN-SECURITY]" value.
362
363 It is RECOMMENDED that the plain text password in the <loginSec:pw>
364 and <loginSec:newPw> elements use printable ASCII characters #x20
365 (space) - #x7E (~) with high entropy, such as 128 bits. If non-ASCII
366 characters are supported with the plain text password, then use a
367 standard for passwords with international characters; the
368 OpaqueString PRECIS profile in [RFC8265] is recommended in the
369 absence of other considerations.
370
371 Example login command that uses the <loginSec:pw> element instead of
372 the <pw> element ([RFC5730]) to establish the session and includes
373 the <loginSec:userAgent> element:
374
375 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
376 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
377 C: <command>
378 C: <login>
379 C: <clID>ClientX</clID>
380 C: <pw>[LOGIN-SECURITY]</pw>
381 C: <options>
382 C: <version>1.0</version>
383 C: <lang>en</lang>
384 C: </options>
385 C: <svcs>
386 C: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
387 C: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
388 C: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
389 C: <svcExtension>
390 C: <extURI>urn:ietf:params:xml:ns:epp:loginSec-1.0</extURI>
391 C: </svcExtension>
392 C: </svcs>
393 C: </login>
394 C: <extension>
395 C: <loginSec:loginSec
396 C: xmlns:loginSec=
397 C: "urn:ietf:params:xml:ns:epp:loginSec-1.0">
398 C: <loginSec:userAgent>
399 C: <loginSec:app>EPP SDK 1.0.0</loginSec:app>
400 C: <loginSec:tech>Vendor Java 11.0.6</loginSec:tech>
401 C: <loginSec:os>x86_64 Mac OS X 10.15.2</loginSec:os>
402 C: </loginSec:userAgent>
403 C: <loginSec:pw>this is a long password</loginSec:pw>
404 C: </loginSec:loginSec>
405 C: </extension>
406 C: <clTRID>ABC-12345</clTRID>
407 C: </command>
408 C:</epp>
409
410 Example login command that uses the <loginSec:pw> element instead of
411 the <pw> element ([RFC5730]) to establish the session and that uses
412 the <loginSec:newPW> element instead of the <newPW> element
413 ([RFC5730]) to set the new password:
414
415 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
416 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
417 C: <command>
418 C: <login>
419 C: <clID>ClientX</clID>
420 C: <pw>[LOGIN-SECURITY]</pw>
421 C: <newPW>[LOGIN-SECURITY]</newPW>
422 C: <options>
423 C: <version>1.0</version>
424 C: <lang>en</lang>
425 C: </options>
426 C: <svcs>
427 C: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
428 C: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
429 C: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
430 C: <svcExtension>
431 C: <extURI>urn:ietf:params:xml:ns:epp:loginSec-1.0</extURI>
432 C: </svcExtension>
433 C: </svcs>
434 C: </login>
435 C: <extension>
436 C: <loginSec:loginSec
437 C: xmlns:loginSec=
438 C: "urn:ietf:params:xml:ns:epp:loginSec-1.0">
439 C: <loginSec:pw>this is a long password
440 C: </loginSec:pw>
441 C: <loginSec:newPW>new password that is still long
442 C: </loginSec:newPW>
443 C: </loginSec:loginSec>
444 C: </extension>
445 C: <clTRID>ABC-12345</clTRID>
446 C: </command>
447 C:</epp>
448
449 Example login command that uses the <pw> element ([RFC5730]) to
450 establish the session and that uses the <loginSec:newPW> element
451 instead of the <newPW> element ([RFC5730]) to set the new password:
452
453 C:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
454 C:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
455 C: <command>
456 C: <login>
457 C: <clID>ClientX</clID>
458 C: <pw>shortpassword</pw>
459 C: <newPW>[LOGIN-SECURITY]</newPW>
460 C: <options>
461 C: <version>1.0</version>
462 C: <lang>en</lang>
463 C: </options>
464 C: <svcs>
465 C: <objURI>urn:ietf:params:xml:ns:obj1</objURI>
466 C: <objURI>urn:ietf:params:xml:ns:obj2</objURI>
467 C: <objURI>urn:ietf:params:xml:ns:obj3</objURI>
468 C: <svcExtension>
469 C: <extURI>urn:ietf:params:xml:ns:epp:loginSec-1.0</extURI>
470 C: </svcExtension>
471 C: </svcs>
472 C: </login>
473 C: <extension>
474 C: <loginSec:loginSec
475 C: xmlns:loginSec=
476 C: "urn:ietf:params:xml:ns:epp:loginSec-1.0">
477 C: <loginSec:newPW>new password that is still long
478 C: </loginSec:newPW>
479 C: </loginSec:loginSec>
480 C: </extension>
481 C: <clTRID>ABC-12345</clTRID>
482 C: </command>
483 C:</epp>
484
485 Upon a completed login command (success or failed), the extension
486 MUST be included in the response when both of the following
487 conditions hold:
488
489 Client supports extension: The client supports the extension based
490 on the <svcExtension> element of the <login> command.
491
492 At least one login security event: The server has identified at
493 least one login security event to communicate to the client.
494
495 The extension to the EPP response uses the <loginSec:loginSecData>
496 element that contains the following child elements:
497
498 <loginSec:event>: One or more <loginSec:event> elements defined in
499 Section 3.1.
500
501 Example EPP response to a successful login command on 2020-03-25,
502 where the password will expire in a week:
503
504 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
505 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
506 S: <response>
507 S: <result code="1000">
508 S: <msg>Command completed successfully</msg>
509 S: </result>
510 S: <extension>
511 S: <loginSec:loginSecData
512 S: xmlns:loginSec=
513 S: "urn:ietf:params:xml:ns:epp:loginSec-1.0">
514 S: <loginSec:event
515 S: type="password"
516 S: level="warning"
517 S: exDate="2020-04-01T22:00:00.0Z"
518 S: lang="en">
519 S: Password expiring in a week
520 S: </loginSec:event>
521 S: </loginSec:loginSecData>
522 S: </extension>
523 S: <trID>
524 S: <clTRID>ABC-12345</clTRID>
525 S: <svTRID>54321-XYZ</svTRID>
526 S: </trID>
527 S: </response>
528 S:</epp>
529
530 Example EPP response to a failed login command where the password has
531 expired and the new password does not meet the server complexity
532 requirements:
533
534 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
535 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
536 S: <response>
537 S: <result code="2200">
538 S: <msg>Authentication error</msg>
539 S: </result>
540 S: <extension>
541 S: <loginSec:loginSecData
542 S: xmlns:loginSec=
543 S: "urn:ietf:params:xml:ns:epp:loginSec-1.0">
544 S: <loginSec:event
545 S: type="password"
546 S: level="error"
547 S: exDate="2020-03-24T22:00:00.0Z">
548 S: Password has expired
549 S: </loginSec:event>
550 S: <loginSec:event
551 S: type="newPW"
552 S: level="error">
553 S: New password does not meet complexity requirements
554 S: </loginSec:event>
555 S: </loginSec:loginSecData>
556 S: </extension>
557 S: <trID>
558 S: <clTRID>ABC-12345</clTRID>
559 S: <svTRID>54321-XYZ</svTRID>
560 S: </trID>
561 S: </response>
562 S:</epp>
563
564 Example EPP response to a successful login command where there is a
565 set of login security events:
566
567 S:<?xml version="1.0" encoding="UTF-8" standalone="no"?>
568 S:<epp xmlns="urn:ietf:params:xml:ns:epp-1.0">
569 S: <response>
570 S: <result code="1000">
571 S: <msg>Command completed successfully</msg>
572 S: </result>
573 S: <extension>
574 S: <loginSec:loginSecData
575 S: xmlns:loginSec=
576 S: "urn:ietf:params:xml:ns:epp:loginSec-1.0">
577 S: <loginSec:event
578 S: type="password"
579 S: level="warning"
580 S: exDate="2020-04-01T22:00:00.0Z"
581 S: lang="en">
582 S: Password expiration soon
583 S: </loginSec:event>
584 S: <loginSec:event
585 S: type="certificate"
586 S: level="warning"
587 S: exDate="2020-04-02T22:00:00.0Z"/>
588 S: <loginSec:event
589 S: type="cipher"
590 S: level="warning"
591 S: value="TLS_RSA_WITH_AES_128_CBC_SHA">
592 S: Non-PFS Cipher negotiated
593 S: </loginSec:event>
594 S: <loginSec:event
595 S: type="tlsProtocol"
596 S: level="warning"
597 S: value="TLSv1.0">
598 S: Insecure TLS protocol negotiated
599 S: </loginSec:event>
600 S: <loginSec:event
601 S: type="stat"
602 S: name="failedLogins"
603 S: level="warning"
604 S: value="100"
605 S: duration="P1D">
606 S: Excessive invalid daily logins
607 S: </loginSec:event>
608 S: <loginSec:event
609 S: type="custom"
610 S: name="myCustomEvent"
611 S: level="warning">
612 S: A custom login security event occurred
613 S: </loginSec:event>
614 S: </loginSec:loginSecData>
615 S: </extension>
616 S: <trID>
617 S: <clTRID>ABC-12345</clTRID>
618 S: <svTRID>54321-XYZ</svTRID>
619 S: </trID>
620 S: </response>
621 S:</epp>
622
623 5. Formal Syntax
624
625 The EPP Login Security Extension schema is presented here.
626
627 The formal syntax shown here is a complete XML Schema representation
628 of the object mapping suitable for automated validation of EPP XML
629 instances. The <CODE BEGINS> and <CODE ENDS> tags are not part of
630 the XML Schema; they are used to note the beginning and ending of the
631 XML Schema for URI registration purposes.
632
633 5.1. Login Security Extension Schema
634
635 <CODE BEGINS>
636 <?xml version="1.0" encoding="UTF-8"?>
637 <schema xmlns="http://www.w3.org/2001/XMLSchema"
638 xmlns:epp="urn:ietf:params:xml:ns:epp-1.0"
639 xmlns:eppcom="urn:ietf:params:xml:ns:eppcom-1.0"
640 xmlns:loginSec="urn:ietf:params:xml:ns:epp:loginSec-1.0"
641 targetNamespace="urn:ietf:params:xml:ns:epp:loginSec-1.0"
642 elementFormDefault="qualified">
643 <!--
644 Import common element types.
645 -->
646 <import namespace="urn:ietf:params:xml:ns:eppcom-1.0" />
647 <import namespace="urn:ietf:params:xml:ns:epp-1.0" />
648 <annotation>
649 <documentation>Extensible Provisioning Protocol v1.0
650 Login Security Extension Schema.</documentation>
651 </annotation>
652 <!-- Login command extension elements -->
653 <element name="loginSec" type="loginSec:loginSecType" />
654 <!--
655 Attributes associated with the login command extension.
656 -->
657 <complexType name="loginSecType">
658 <sequence>
659 <element name="userAgent"
660 type="loginSec:userAgentType" minOccurs="0" />
661 <element name="pw"
662 type="loginSec:pwType" minOccurs="0" />
663 <element name="newPW"
664 type="loginSec:pwType" minOccurs="0" />
665 </sequence>
666 </complexType>
667 <simpleType name="pwType">
668 <restriction base="token">
669 <minLength value="6" />
670 </restriction>
671 </simpleType>
672 <complexType name="userAgentType">
673 <choice>
674 <sequence>
675 <element name="app"
676 type="token" />
677 <element name="tech"
678 type="token" minOccurs="0" />
679 <element name="os"
680 type="token" minOccurs="0" />
681 </sequence>
682 <sequence>
683 <element name="tech"
684 type="token" />
685 <element name="os"
686 type="token" minOccurs="0" />
687 </sequence>
688 <element name="os"
689 type="token" />
690 </choice>
691 </complexType>
692 <!-- Login response extension elements -->
693 <element name="loginSecData"
694 type="loginSec:loginSecDataType" />
695 <complexType name="loginSecDataType">
696 <sequence>
697 <element name="event"
698 type="loginSec:eventType"
699 minOccurs="1" maxOccurs="unbounded" />
700 </sequence>
701 </complexType>
702 <!-- Security event element -->
703 <complexType name="eventType">
704 <simpleContent>
705 <extension base="normalizedString">
706 <attribute name="type"
707 type="loginSec:typeEnum" use="required" />
708 <attribute name="name"
709 type="token" />
710 <attribute name="level"
711 type="loginSec:levelEnum" use="required" />
712 <attribute name="exDate"
713 type="dateTime" />
714 <attribute name="value"
715 type="token" />
716 <attribute name="duration"
717 type="duration" />
718 <attribute name="lang"
719 type="language" default="en" />
720 </extension>
721 </simpleContent>
722 </complexType>
723 <!--
724 Enumerated list of event types, with extensibility via "custom".
725 -->
726 <simpleType name="typeEnum">
727 <restriction base="token">
728 <enumeration value="password" />
729 <enumeration value="certificate" />
730 <enumeration value="cipher" />
731 <enumeration value="tlsProtocol" />
732 <enumeration value="newPW" />
733 <enumeration value="stat" />
734 <enumeration value="custom" />
735 </restriction>
736 </simpleType>
737 <!--
738 Enumerated list of levels.
739 -->
740 <simpleType name="levelEnum">
741 <restriction base="token">
742 <enumeration value="warning" />
743 <enumeration value="error" />
744 </restriction>
745 </simpleType>
746 <!--
747 End of schema.
748 -->
749 </schema>
750 <CODE ENDS>
751
752 6. IANA Considerations
753
754 6.1. XML Namespace
755
756 This document uses URNs to describe XML namespaces and XML schemas
757 conforming to a registry mechanism described in [RFC3688]. The
758 following URI assignment has been made by IANA:
759
760 Registration request for the loginSec namespace:
761
762 URI: urn:ietf:params:xml:ns:epp:loginSec-1.0
763 Registrant Contact: IESG
764 XML: None. Namespace URIs do not represent an XML specification.
765
766 Registration request for the loginSec XML Schema:
767
768 URI: urn:ietf:params:xml:schema:epp:loginSec-1.0
769 Registrant Contact: IESG
770 XML: See the "Formal Syntax" section of this document.
771
772 6.2. EPP Extension Registry
773
774 The EPP extension described in this document has been registered by
775 IANA in the "Extensions for the Extensible Provisioning Protocol
776 (EPP)" registry described in [RFC7451]. The details of the
777 registration are as follows:
778
779 Name of Extension: "Login Security Extension for the Extensible
780 Provisioning Protocol (EPP)"
781 Document status: Standards Track
782 Reference: RFC 8807
783 Registrant Name and Email Address: IESG, <iesg@ietf.org>
784 Top-Level Domains(TLDs): Any
785 IPR Disclosure: None
786 Status: Active
787 Notes: None
788
789 7. Security Considerations
790
791 The security considerations of [RFC5730] apply in this document, and
792 this document enhances these considerations.
793
794 The extension leaves the password (<pw> element) and new password
795 (<newPW> element) minimum length greater than 6 characters and the
796 maximum length up to server policy. The server SHOULD enforce
797 minimum and maximum length requirements that are appropriate for
798 their operating environment. One example of a guideline for password
799 length policies can be found in Section 5 of NIST Special Publication
800 800-63B (https://pages.nist.gov/800-63-3/sp800-63b.html).
801
802 The client SHOULD NOT decrease the security of a new password by
803 decreasing the length of the current password. For example, a client
804 with a 20-character password set using the extension should not use
805 the login command in [RFC5730] without using the extension to set a
806 new password that is less than or equal to 16 characters.
807
808 The extension provides an extensible list of login security events to
809 inform clients of connection and login warnings and errors. The
810 server returning of security events to unauthenticated users needs to
811 take into account the security/privacy issues of returning
812 information to potential attackers.
813
814 The user-agent information represents the client system of a system-
815 to-system interface, so the user-agent information MUST NOT provide
816 any ability to track individual users or classes of users.
817
818 8. References
819
820 8.1. Normative References
821
822 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
823 Requirement Levels", BCP 14, RFC 2119,
824 DOI 10.17487/RFC2119, March 1997,
825 <https://www.rfc-editor.org/info/rfc2119>.
826
827 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688,
828 DOI 10.17487/RFC3688, January 2004,
829 <https://www.rfc-editor.org/info/rfc3688>.
830
831 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
832 Specifications: ABNF", STD 68, RFC 5234,
833 DOI 10.17487/RFC5234, January 2008,
834 <https://www.rfc-editor.org/info/rfc5234>.
835
836 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)",
837 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009,
838 <https://www.rfc-editor.org/info/rfc5730>.
839
840 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC
841 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174,
842 May 2017, <https://www.rfc-editor.org/info/rfc8174>.
843
844 [W3C.REC-xmlschema-2-20041028]
845 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes
846 Second Edition", W3C Recommendation REC-xmlschema-
847 2-20041028, October 2004,
848 <http://www.w3.org/TR/2004/REC-xmlschema-2-20041028>.
849
850 8.2. Informative References
851
852 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible
853 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451,
854 February 2015, <https://www.rfc-editor.org/info/rfc7451>.
855
856 [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation,
857 Enforcement, and Comparison of Internationalized Strings
858 Representing Usernames and Passwords", RFC 8265,
859 DOI 10.17487/RFC8265, October 2017,
860 <https://www.rfc-editor.org/info/rfc8265>.
861
862 Acknowledgements
863
864 The authors wish to thank the following persons for their feedback
865 and suggestions: Martin Casanova, Scott Hollenbeck, Barry Leiba,
866 Patrick Mevzek, and Joseph Yee.
867
868 Authors' Addresses
869
870 James Gould
871 VeriSign, Inc.
872 12061 Bluemont Way
873 Reston, VA 20190
874 United States of America
875
876 Email: jgould@verisign.com
877 URI: http://www.verisign.com
878
879
880 Matthew Pozun
881 VeriSign, Inc.
882 12061 Bluemont Way
883 Reston, VA 20190
884 United States of America
885
886 Email: mpozun@verisign.com
887 URI: http://www.verisign.com
888
The IETF is responsible for the creation and maintenance of the DNS RFCs. The ICANN DNS RFC annotation project provides a forum for collecting community annotations on these RFCs as an aid to understanding for implementers and any interested parties. The annotations displayed here are not the result of the IETF consensus process.
This RFC is included in the DNS RFCs annotation project whose home page is here.