idnits 2.17.00 (12 Aug 2021) /tmp/idnits24107/draft-ietf-regext-login-security-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (February 26, 2020) is 808 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Looks like a reference, but probably isn't: '1' on line 936 == Missing Reference: 'LOGIN-SECURITY' is mentioned on line 271, but not defined -- Looks like a reference, but probably isn't: '2' on line 939 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Gould 3 Internet-Draft M. Pozun 4 Intended status: Standards Track VeriSign, Inc. 5 Expires: August 29, 2020 February 26, 2020 7 Login Security Extension for the Extensible Provisioning Protocol (EPP) 8 draft-ietf-regext-login-security-10 10 Abstract 12 The Extensible Provisioning Protocol (EPP) includes a client 13 authentication scheme that is based on a user identifier and 14 password. The structure of the password field is defined by an XML 15 Schema data type that specifies minimum and maximum password length 16 values, but there are no other provisions for password management 17 other than changing the password. This document describes an EPP 18 extension that allows longer passwords to be created and adds 19 additional security features to the EPP login command and response. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at https://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 29, 2020. 38 Copyright Notice 40 Copyright (c) 2020 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (https://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 57 2. Migrating to Newer Versions of This Extension . . . . . . . . 4 58 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Event . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. "[LOGIN-SECURITY]" Password . . . . . . . . . . . . . . . 6 61 3.3. Dates and Times . . . . . . . . . . . . . . . . . . . . . 7 62 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. EPP Command . . . . . . . . . . . . . . . . . . . 7 64 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 15 65 5.1. Login Security Extension Schema . . . . . . . . . . . . . 15 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 67 6.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 17 68 6.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 18 69 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 18 70 7.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 19 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 20 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 20 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 20 75 10.2. Informative References . . . . . . . . . . . . . . . . . 21 76 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 21 77 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 21 78 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 21 79 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 21 80 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 22 81 A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 22 82 A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 22 83 A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 22 84 A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 22 85 A.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 23 86 A.9. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 23 87 A.10. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 24 88 A.11. Change from REGEXT 06 to REGEXT 07 . . . . . . . . . . . 24 89 A.12. Change from REGEXT 07 to REGEXT 08 . . . . . . . . . . . 24 90 A.13. Change from REGEXT 08 to REGEXT 09 . . . . . . . . . . . 26 91 A.14. Change from REGEXT 09 to REGEXT 10 . . . . . . . . . . . 27 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 94 1. Introduction 96 This document describes an Extensible Provisioning Protocol (EPP) 97 extension for enhancing the security of the EPP login command in EPP 98 [RFC5730]. EPP [RFC5730] includes a maximum password length of 16 99 characters that inhibits implementing stronger password security 100 policies with higher entropy. The enhancements include supporting 101 longer passwords (or passphrases) than the 16-character maximum and 102 providing a list of security events in the login response. The 103 password (current and new) in EPP [RFC5730] can be overridden by the 104 password included in the extension to extend past the 16-character 105 maximum. The security events supported include: password expiry, 106 client certificate expiry, insecure cipher, insecure TLS protocol, 107 new password complexity, login security statistical warning, and a 108 custom event. The attributes supported by the security events 109 include identifying the event type or sub-type, indicating the 110 security level of warning or error, a future or past-due expiration 111 date, the value that resulted in the event, the duration of the 112 statistical event, and a free-form description with an optional 113 language. 115 1.1. Conventions Used in This Document 117 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 118 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 119 "OPTIONAL" in this document are to be interpreted as described in BCP 120 14 [RFC2119] [RFC8174] when, and only when, they appear in all 121 capitals, as shown here. 123 XML is case sensitive. Unless stated otherwise, XML specifications 124 and examples provided in this document MUST be interpreted in the 125 character case presented in order to develop a conforming 126 implementation. 128 In examples, "C:" represents lines sent by a protocol client and "S:" 129 represents lines returned by a protocol server. Indentation and 130 white space in examples are provided only to illustrate element 131 relationships and are not a required feature of this protocol. 133 "loginSec-1.0" is used as an abbreviation for 134 "urn:ietf:params:xml:ns:epp:loginSec-1.0". The XML namespace prefix 135 "loginSec" is used, but implementations MUST NOT depend on it and 136 instead employ a proper namespace-aware XML parser and serializer to 137 interpret and output the XML documents. 139 "whitespace" is defined by the XML schema whiteSpace datatype in 140 [W3C.REC-xmlschema-2-20041028], which only includes the ASCII 141 whitespace characters #x9 (tab), #xA (linefeed), #xD (carriage 142 return), and #x20 (space). 144 2. Migrating to Newer Versions of This Extension 146 Servers which implement this extension SHOULD provide a way for 147 clients to progressively update their implementations when a new 148 version of the extension is deployed. A newer version of the 149 extension is expected to use an XML namespace with a higher version 150 number than the prior versions. 152 Servers SHOULD (for a temporary migration period up to server policy) 153 provide support for older versions of the extension in parallel to 154 the newest version, and allow clients to select their preferred 155 version via the element of the command. 157 If a client requests multiple versions of the extension at login, 158 then, when preparing responses to commands which do not include 159 extension elements, the server SHOULD only include extension elements 160 in the namespace of the newest version of the extension requested by 161 the client. 163 When preparing responses to commands which do include extension 164 elements, the server SHOULD only include extension elements for the 165 extension versions present in the command. 167 3. Object Attributes 169 This extension adds additional elements to [RFC5730] login command 170 and response. Only those new elements are described here. 172 3.1. Event 174 A security event, using the element, represents 175 either a warning or error identified by the server after the client 176 has connected and submitted the login command. The 177 element is contained in a list of one or more elements in the 178 element, so there MAY be multiple events 179 returned that provide information for the client to address. The 180 MAY include a free-form description. All of the 181 security events use a consistent set of attributes, where the exact 182 set of applicable attributes is based on the event type. The 183 supported set of element attributes include: 185 "type": A REQUIRED attribute that defines the type of security 186 event. The enumerated list of "type" values includes: 188 "password": Identifies a password expiry event, where the 189 password expires in the future or has expired based on the 190 "exDate" date and time. The "exDate" attribute MUST be set 191 with the password expiry date and time. 192 "certificate": Identifies a client certificate expiry event, 193 where the client certificate will expire at the "exDate" date 194 and time. The "exDate" attribute MUST be set with the 195 certificate expiry date and time. 196 "cipher": Identifies the use of an insecure or deprecated TLS 197 cipher suite. The "name" attribute MUST be set with the name 198 of the cipher suite, which is free-form and is not expected 199 to be parsed and automatically addressed by the client. An 200 example of cipher suite names can be found in the TLS Cipher 201 Suites of the Transport Layer Security (TLS) Parameters IANA 202 Registry [1]. 203 "tlsProtocol": Identifies the use of an insecure or deprecated 204 TLS protocol. The "name" attribute MUST be set with the name 205 of the TLS protocol, which is free-form and is not expected 206 to be parsed and automatically addressed by the client. 207 "newPW": The new password does not meet the server password 208 complexity requirements. 209 "stat": Provides a login security statistical warning that MUST 210 set the "name" attribute to the name of the statistic sub- 211 type. 212 "custom": Custom event type that MUST set the "name" attribute 213 with the custom event type name. 214 "name": Used to define a sub-type when the "type" attribute is not 215 "custom" or the full type name when the "type" attribute is 216 "custom". The "name" attribute MUST be set when the "type" 217 attribute is "stat" or "custom". The possible set of "name" 218 values, by event type, can be discovered / negotiated out of band 219 to EPP or using a separate EPP extension designed to provide 220 server policy information to the client. 221 "level": Defines the level of the event as either "warning" for a 222 warning event that needs action, or "error" for an error event 223 that requires immediate action. 224 "exDate": Contains the date and time that a "warning" level has or 225 will become an "error" level. At expiry there MAY be a 226 connection failure or MAY be a login failure. An example is an 227 expired certification that will result in a connection failure or 228 an expired password that may result in a login failure. 229 "value": Identifies the value that resulted in the login security 230 event. An example is the negotiated insecure cipher suite or the 231 negotiated insecure TLS protocol. 232 "duration": Defines the duration that a statistical event is 233 associated with, ending when the login command was received. The 234 format of the duration is defined by the duration primitive 235 datatype in section 3.2.6 of [W3C.REC-xmlschema-2-20041028]. 237 "lang": Identifies the negotiated language of the free-form 238 description. The format of the language is defined by the 239 language primitive datatype in section 3.3.3 of 240 [W3C.REC-xmlschema-2-20041028]. The default is "en" (English). 242 Example login security event for password expiration, where the 243 current date is 2020-03-25: 245 250 Password expiration soon 251 253 Example login security event for identifying 100 failed logins over 254 the last day, using the "stat" sub-type of "failedLogins": 256 262 Excessive invalid daily logins 263 265 3.2. "[LOGIN-SECURITY]" Password 267 When the [RFC5730] element contains the predefined value of 268 "[LOGIN-SECURITY]", the element overrides the 269 element, which is a constant value for the server to use the 270 element for the password. Similarly, when the 271 [RFC5730] element contains the predefined value of "[LOGIN- 272 SECURITY]", the element overrides the 273 element, which is a constant value for the server to use the 274 element for the new password. The "[LOGIN- 275 SECURITY]" pre-defined string MUST be supported by the server for the 276 client to explicitly indicate to the server whether to use 277 element in place of the [RFC5730] element or to 278 use the in place of the [RFC5730] element. 279 The server MUST NOT allow the client to set the password to the value 280 "[LOGIN-SECURITY]". 282 3.3. Dates and Times 284 Date and time attribute values MUST be represented in Universal 285 Coordinated Time (UTC) using the Gregorian calendar. The extended 286 date-time form using upper case "T" and "Z" characters defined in 287 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 288 values, as XML Schema does not support truncated date-time forms or 289 lower case "T" and "Z" characters. 291 4. EPP Command Mapping 293 A detailed description of the EPP syntax and semantics can be found 294 in the EPP core protocol specification [RFC5730]. 296 4.1. EPP Command 298 This extension defines additional elements to extend the EPP 299 command and response to be used in conjunction with [RFC5730]. 301 The EPP command is used to establish a session with an EPP 302 server. This extension overrides the password that is passed with 303 the [RFC5730] or the element as defined in Section 3.2. 304 A element is sent along with the [RFC5730] 305 command and MUST contain at least one of the following child 306 elements: 308 : OPTIONAL client user agent information that 309 identifies the client application software, technology, and 310 operating system used by the server to identify functional or 311 security constraints, current security issues, and potential 312 future functional or security issues for the client. The server 313 may use the information for real-time identification and client 314 notification of security issues, such as keying off of the client 315 application software for executing security rule checks. The 316 server may capture the information to identify future security 317 policy issues, such as deprecating or removing TLS cipher suites 318 or TLS protocols. The element MUST contain 319 at least one of the following child elements: 321 : OPTIONAL name of the client application software 322 with version if available, such as the name of the client SDK 323 "EPP SDK 1.0.0". The element value can be 324 created by appending the version number to the name of the 325 application software, such as the Augmented Backus-Naur Form 326 (ABNF) grammar [RFC5234] format: 328 app = name SP version 329 name = 1*VCHAR 330 version = 1*VCHAR 331 : OPTIONAL technology used for the client 332 software with version if available, such as "Vendor Java 333 11.0.6". The element value can be created by 334 including the technology vendor, technology name, and 335 technology version, such as the Augmented Backus-Naur Form 336 (ABNF) grammar [RFC5234] format: 338 tech = vendor SP name SP version 339 vendor = 1*VCHAR 340 name = 1*VCHAR 341 version = 1*VCHAR 342 : OPTIONAL client operating system used with 343 version if available, such as "x86_64 Mac OS X 10.15.2". The 344 element value can be created by including the 345 operating system architecture, operating system name, and 346 operating system version, such as the Augmented Backus-Naur 347 Form (ABNF) grammar [RFC5234] format: 349 os = arch SP name SP version 350 arch = 1*VCHAR 351 name = 1*VCHAR 352 version = 1*VCHAR 353 : OPTIONAL plain text password that is case sensitive, 354 has a minimum length of 6 characters, and has a maximum length 355 that is up to server policy. All leading and trailing whitespace 356 is removed, and all internal contiguous whitespace that includes 357 #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20 358 (space) is replaced with a single #x20 (space). This element 359 MUST only be set if the [RFC5730] element is set to the 360 "[LOGIN-SECURITY]" value. 361 : OPTIONAL plain text new password that is case 362 sensitive, has a minimum length of 6 characters, and has a 363 maximum length that is up to server policy. All leading and 364 trailing whitespace is removed, and all internal contiguous 365 whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage 366 return), and #x20 (space) is replaced with a single #x20 (space). 367 This element MUST only be set if the [RFC5730] element is 368 set to the "[LOGIN-SECURITY]" value. 370 It is RECOMMENDED that the plain text password in the 371 and elements use printable ASCII characters #x20 372 (space) - #x7E (~), with high entropy, such as 128 bits. If non- 373 ASCII characters are supported with the plain text password, then use 374 a standard for passwords with international characters; the 375 OpaqueString PRECIS profile in [RFC8265] is recommended in the 376 absence of other considerations. 378 Example login command that uses the element instead of 379 the [RFC5730] element to establish the session and includes the 380 element: 382 C: 383 C: 384 C: 385 C: 386 C: ClientX 387 C: [LOGIN-SECURITY] 388 C: 389 C: 1.0 390 C: en 391 C: 392 C: 393 C: urn:ietf:params:xml:ns:obj1 394 C: urn:ietf:params:xml:ns:obj2 395 C: urn:ietf:params:xml:ns:obj3 396 C: 397 C: urn:ietf:params:xml:ns:epp:loginSec-1.0 398 C: 399 C: 400 C: 401 C: 402 C: 405 C: 406 C: EPP SDK 1.0.0 407 C: Vendor Java 11.0.6 408 C: x86_64 Mac OS X 10.15.2 409 C: 410 C: this is a long password 411 C: 412 C: 413 C: ABC-12345 414 C: 415 C: 416 Example login command that uses the element instead of 417 the [RFC5730] element to establish the session, and uses the 418 element instead of the [RFC5730] element to 419 set the new password: 421 C: 422 C: 423 C: 424 C: 425 C: ClientX 426 C: [LOGIN-SECURITY] 427 C: [LOGIN-SECURITY] 428 C: 429 C: 1.0 430 C: en 431 C: 432 C: 433 C: urn:ietf:params:xml:ns:obj1 434 C: urn:ietf:params:xml:ns:obj2 435 C: urn:ietf:params:xml:ns:obj3 436 C: 437 C: urn:ietf:params:xml:ns:epp:loginSec-1.0 438 C: 439 C: 440 C: 441 C: 442 C: 445 C: this is a long password 446 C: 447 C: new password that is still long 448 C: 449 C: 450 C: 451 C: ABC-12345 452 C: 453 C: 454 Example login command that uses the [RFC5730] element to 455 establish the session, and uses the element instead 456 of the [RFC5730] element to set the new password: 458 C: 459 C: 460 C: 461 C: 462 C: ClientX 463 C: shortpassword 464 C: [LOGIN-SECURITY] 465 C: 466 C: 1.0 467 C: en 468 C: 469 C: 470 C: urn:ietf:params:xml:ns:obj1 471 C: urn:ietf:params:xml:ns:obj2 472 C: urn:ietf:params:xml:ns:obj3 473 C: 474 C: urn:ietf:params:xml:ns:epp:loginSec-1.0 475 C: 476 C: 477 C: 478 C: 479 C: 482 C: new password that is still long 483 C: 484 C: 485 C: 486 C: ABC-12345 487 C: 488 C: 490 Upon a completed login command (success or failed), the extension 491 MUST be included in the response when both of the following 492 conditions hold: 494 Client supports extension: The client supports the extension based 495 on the element of the command. 496 At least one login security event: The server has identified at 497 least one login security event to communicate to the client. 499 The extension to the EPP response uses the 500 element that contains the following child elements: 502 : One or more elements defined in 503 Section 3.1. 505 Example EPP response to a successful login command on 2020-03-25, 506 where the password will expire in a week: 508 S: 509 S: 510 S: 511 S: 512 S: Command completed successfully 513 S: 514 S: 515 S: 518 S: 523 S: Password expiring in a week 524 S: 525 S: 526 S: 527 S: 528 S: ABC-12345 529 S: 54321-XYZ 530 S: 531 S: 532 S: 533 Example EPP response to a failed login command where the password has 534 expired and the new password does not meet the server complexity 535 requirements: 537 S: 538 S: 539 S: 540 S: 541 S: Authentication error 542 S: 543 S: 544 S: 547 S: 551 S: Password has expired 552 S: 553 S: 556 S: New password does not meet complexity requirements 557 S: 558 S: 559 S: 560 S: 561 S: ABC-12345 562 S: 54321-XYZ 563 S: 564 S: 565 S: 567 Example EPP response to a successful login command where there is a 568 set of login security events: 570 S: 571 S: 572 S: 573 S: 574 S: Command completed successfully 575 S: 576 S: 577 S: 580 S: 585 S: Password expiration soon 586 S: 587 S: 591 S: 595 S: Non-PFS Cipher negotiated 596 S: 597 S: 601 S: Insecure TLS protocol negotiated 602 S: 603 S: 609 S: Excessive invalid daily logins 610 S: 611 S: 615 S: A custom login security event occured 616 S: 617 S: 618 S: 619 S: 620 S: ABC-12345 621 S: 54321-XYZ 622 S: 623 S: 624 S: 626 5. Formal Syntax 628 The EPP Login Security Extension schema is presented here. 630 The formal syntax presented here is a complete XML schema 631 representation of the object mapping suitable for automated 632 validation of EPP XML instances. The BEGIN and END tags are not part 633 of the XML schema; they are used to note the beginning and ending of 634 the XML schema for URI registration purposes. 636 5.1. Login Security Extension Schema 638 BEGIN 639 640 646 649 650 651 652 Extensible Provisioning Protocol v1.0 653 Login Security Extension Schema. 654 655 656 657 660 661 662 664 666 668 669 670 671 672 673 675 676 677 678 679 681 683 685 686 687 689 691 692 694 695 696 697 699 700 701 704 705 706 707 708 709 710 712 714 716 718 720 722 724 725 726 727 730 731 732 733 734 735 736 737 738 739 740 741 744 745 746 747 748 749 750 753 754 END 756 6. IANA Considerations 758 6.1. XML Namespace 760 This document uses URNs to describe XML namespaces and XML schemas 761 conforming to a registry mechanism described in [RFC3688]. The 762 following URI assignment is requested of IANA: 764 Registration request for the loginSec namespace: 766 URI: urn:ietf:params:xml:ns:epp:loginSec-1.0 767 Registrant Contact: IESG 768 XML: None. Namespace URIs do not represent an XML specification. 770 Registration request for the loginSec XML schema: 772 URI: urn:ietf:params:xml:schema:epp:loginSec-1.0 773 Registrant Contact: IESG 774 XML: See the "Formal Syntax" section of this document. 776 6.2. EPP Extension Registry 778 The EPP extension described in this document should be registered by 779 the IANA in the EPP Extension Registry described in [RFC7451]. The 780 details of the registration are as follows: 782 Name of Extension: "Login Security Extension for the Extensible 783 Provisioning Protocol (EPP)" 785 Document status: Standards Track 787 Reference: (insert reference to RFC version of this document) 789 Registrant Name and Email Address: IESG, 791 TLDs: Any 793 IPR Disclosure: None 795 Status: Active 797 Notes: None 799 7. Implementation Status 801 Note to RFC Editor: Please remove this section and the reference to 802 RFC 7942 [RFC7942] before publication. 804 This section records the status of known implementations of the 805 protocol defined by this specification at the time of posting of this 806 Internet-Draft, and is based on a proposal described in RFC 7942 807 [RFC7942]. The description of implementations in this section is 808 intended to assist the IETF in its decision processes in progressing 809 drafts to RFCs. Please note that the listing of any individual 810 implementation here does not imply endorsement by the IETF. 811 Furthermore, no effort has been spent to verify the information 812 presented here that was supplied by IETF contributors. This is not 813 intended as, and must not be construed to be, a catalog of available 814 implementations or their features. Readers are advised to note that 815 other implementations may exist. 817 According to RFC 7942 [RFC7942], "this will allow reviewers and 818 working groups to assign due consideration to documents that have the 819 benefit of running code, which may serve as evidence of valuable 820 experimentation and feedback that have made the implemented protocols 821 more mature. It is up to the individual working groups to use this 822 information as they see fit". 824 7.1. Verisign EPP SDK 826 Organization: Verisign Inc. 828 Name: Verisign EPP SDK 830 Description: The Verisign EPP SDK includes both a full client 831 implementation and a full server stub implementation of draft-ietf- 832 regext-login-security. 834 Level of maturity: Development 836 Coverage: All aspects of the protocol are implemented. 838 Licensing: GNU Lesser General Public License 840 Contact: jgould@verisign.com 842 URL: https://www.verisign.com/en_US/channel-resources/domain- 843 registry-products/epp-sdks 845 8. Security Considerations 847 The Security Considerations of [RFC5730] apply in this document, and 848 this document enhances these considerations. 850 The extension leaves the password ( element) and new password 851 ( element) minimum length greater than 6 characters and the 852 maximum length up to server policy. The server SHOULD enforce 853 minimum and maximum length requirements that are appropriate for 854 their operating environment. One example of a guideline for password 855 length policies can be found in section 5 of NIST Special Publication 856 800-63B [2]. 858 The client SHOULD NOT decrease the security of a new password by 859 decreasing the length of the current password. For example, a client 860 with a 20 character password set using the extension, should not use 861 the login command in [RFC5730] without using the extension, to set a 862 new password that is less than or equal to 16 characters. 864 The extension provides an extensible list of login security events to 865 inform clients of connection and login warnings and errors. The 866 server returning of security events to unauthenticated users needs to 867 take into account the security/privacy issues of returning 868 information to potential attackers. 870 The user agent information represents the client system of a system- 871 to-system interface, so the user agent information MUST NOT provide 872 any ability to track individual users or classes of users. 874 9. Acknowledgements 876 The authors wish to thank the following persons for their feedback 877 and suggestions: 879 o Martin Casanova 880 o Scott Hollenbeck 881 o Barry Leiba 882 o Patrick Mevzek 883 o Joseph Yee 885 10. References 887 10.1. Normative References 889 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 890 Requirement Levels", BCP 14, RFC 2119, 891 DOI 10.17487/RFC2119, March 1997, 892 . 894 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 895 DOI 10.17487/RFC3688, January 2004, 896 . 898 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 899 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 900 . 902 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 903 Code: The Implementation Status Section", BCP 205, 904 RFC 7942, DOI 10.17487/RFC7942, July 2016, 905 . 907 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 908 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 909 May 2017, . 911 [W3C.REC-xmlschema-2-20041028] 912 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 913 Second Edition", World Wide Web Consortium Recommendation 914 REC-xmlschema-2-20041028, October 2004, 915 . 917 10.2. Informative References 919 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 920 Specifications: ABNF", STD 68, RFC 5234, 921 DOI 10.17487/RFC5234, January 2008, 922 . 924 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 925 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 926 February 2015, . 928 [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, 929 Enforcement, and Comparison of Internationalized Strings 930 Representing Usernames and Passwords", RFC 8265, 931 DOI 10.17487/RFC8265, October 2017, 932 . 934 10.3. URIs 936 [1] https://www.iana.org/assignments/tls-parameters/tls- 937 parameters.xhtml#tls-parameters-4 939 [2] https://pages.nist.gov/800-63-3/sp800-63b.html 941 Appendix A. Change History 943 [[RFC Editor: Please remove this section.]] 945 A.1. Change from 00 to 01 947 1. Based on the feedback from Patrick Mevzek and a proposal from 948 Scott Hollenbeck, changed the minimum length of the password from 949 8 to 6, revised the description of the password, and added text 950 in the Security Considerations section for the server password 951 length policy. 953 A.2. Change from 01 to 02 955 1. Changed the XML namespace from urn:ietf:params:xml:ns:loginSec- 956 0.3 to urn:ietf:params:xml:ns:epp:loginSec-0.3, and changed the 957 XML schema registration from urn:ietf:params:xml:ns:loginSec-0.3 958 to urn:ietf:params:xml:schema:epp:loginSec-0.3 based on a request 959 from IANA with draft-ietf-regext-allocation-token. 961 A.3. Change from 02 to 03 963 1. Updates based on the review by Patrick Mevzek, that include: 965 1. Fix the inconsistent case for newPW, that required a global 966 change in the draft text and an update to the XML schema to 967 "urn:ietf:params:xml:ns:loginSec-0.3". 968 2. Changed "contains the following child elements" to "MUST 969 contain at least one of the following child elements", 970 section "EPP Command" to ensure that an empty 971 element is not passed. 972 3. Add "The client SHOULD NOT decrease the security of a new 973 password by decreasing the length of the current password." 974 along with an example to the "Security Considerations" 975 section. 977 A.4. Change from 03 to REGEXT 00 979 1. Changed to regext working group draft by changing draft-gould- 980 regext-login-security to draft-ietf-regext-login-security. 982 A.5. Change from REGEXT 00 to REGEXT 01 984 1. Changed the element to be structured with 985 the , , and sub- 986 elements. This was based on the feedback from Martin Casanova. 987 This resulted in the need to change the XML namespace from 988 urn:ietf:params:xml:ns:epp:loginSec-0.3 to 989 urn:ietf:params:xml:ns:epp:loginSec-0.4. 991 A.6. Change from REGEXT 01 to REGEXT 02 993 1. Updated the Implementation Status section from "TBD" to include 994 the Verisign EPP SDK implementation. 996 A.7. Change from REGEXT 02 to REGEXT 03 998 1. Revised the description of the "duration" attribute to clarify 999 that it ends when the login command was received and to clarify 1000 the format, based on the feedback from Martin Casanova. 1001 2. Revised the sentence 'Upon a completed login command (success or 1002 failed), the extension MUST be included in the response based on 1003 the following conditions:' to 'Upon a completed login command 1004 (success or failed), the extension MUST be included in the 1005 response based on both of the following conditions:' based on the 1006 feedback from Patrick Mevzek. 1007 3. Updates based on the review by Joseph Yee, that include: 1009 1. Revised the description of the "name" 1010 attribute read 'Used to define a sub-type when the "type" 1011 attribute is not "custom" or the full type name when the 1012 "type" attribute is "custom"'. The definition of the "stat" 1013 type was updated to 'Provides a login security statistical 1014 warning that MUST set the "name" attribute to the name of the 1015 statistic.' 1016 2. Added the following sentence 'The server MUST NOT allow the 1017 client to set the password to the value "[LOGIN-SECURITY]".' 1018 to address the corner case where the constant is used as the 1019 password. 1020 3. Revised the description of the element 1021 to read 'The element MUST contain at 1022 least one of the following child elements:'. 1023 4. Revised the description of the to match the 1024 child elements that can be passed, by changing "client software" 1025 to "client application software" and change "language" to 1026 "technology". 1027 5. Changed the XML namespace from 1028 urn:ietf:params:xml:ns:epp:loginSec-0.4 to 1029 urn:ietf:params:xml:ns:epp:loginSec-1.0. 1031 A.8. Change from REGEXT 03 to REGEXT 04 1033 Updates based on the review by Joseph Yee, that include: 1035 1. Update the definition of the "stat" security event type to 1036 reference sub-type to match the language for the "name" 1037 attribute. 1038 2. Added the sentence 'The "name" attribute MUST be set when the 1039 "type" attribute is "stat" or "custom".' to the definition of the 1040 "name" attribute for clarity. 1041 3. Update the definition of the "userAgentType" in the XML schema to 1042 require at least one sub-element using a element. 1044 A.9. Change from REGEXT 04 to REGEXT 05 1046 Updates based on the review by Barry Leiba, that include: 1048 1. In section 1.1, updated to use BCP 14 boilerplate and references 1049 as defined in RFC 8174. 1050 2. In section 1.1, change "REQUIRED" to "required". 1051 3. Keep the "Migration to Newer Versions of This Extension" section 1052 by removing the note for removal to the RFC Editor. 1054 4. In section 3.1, change "MAY be multiple events returned that 1055 provides information" to "MAY be multiple events returned that 1056 provide information". 1057 5. In section 3.1, change "free form" to "free-form". 1058 6. In section 3.1, change "The enumerated list of "type" values 1059 include:" to "The enumerated list of "type" values includes:". 1060 7. In section 3.1, change "Identifies the language of the free-form 1061 description if the negotiated language is something other than 1062 the default value of "en" (English)." to "Identifies the 1063 negotiated language of the free-form description. The default is 1064 "en" (English). 1065 8. In section 3.1, change example description from "Example login 1066 security event for a password expiring in a week:" to "Example 1067 login security event for password expiration, where the current 1068 date is 2018-03-25:". 1069 9. In section 4.1, change "Example EPP response to a successful 1070 login command where the password will expire in a week:" to 1071 "Example EPP response to a successful login command on 1072 2018-03-25, where the password will expire in a week:". 1074 A.10. Change from REGEXT 05 to REGEXT 06 1076 Updates based on the review by Brian Carpenter, that include: 1078 1. In section 1, change the references to RFC 5730 to use links. 1079 2. In section 2, change "(for a temporary migration period)" to 1080 "(for a temporary migration period up to server policy)". 1082 A.11. Change from REGEXT 06 to REGEXT 07 1084 1. Updates based on feedback from Barry Leiba, added recommendations 1085 on the characters used for the plain text password. Recommended 1086 the use of printable ASCII passwords and if non-ASCII characters 1087 are supported, to use a standard for passwords with international 1088 characters, such as the OpaqueString PRECIS profile in [RFC8265]. 1089 2. Based on the feedback from Carlos Pignataro, added "[[RFC Editor: 1090 Please remove this section.]]" to the "Change History" section. 1092 A.12. Change from REGEXT 07 to REGEXT 08 1094 1. Based on feedback from Eric Vyncke during the IESG review, 1095 changed [RFC8174] from the informative references into the 1096 normative references. 1097 2. Based on feedback from Alissa Cooper during the IESG review, 1098 changed the sentence "One schema is presented here that is the 1099 EPP Login Security Extension schema." in section 5 to "The EPP 1100 Login Security Extension schema is presented here.". 1101 3. Changed "sever policy" to "server policy" in section 8. 1103 4. Updates based on feedback from Roman Danyliw during the IESG 1104 review: 1106 1. Changed "pasword" to "password" in section 1. 1107 2. In section 3.1, added a reference to section 3.3.3 of 1108 [W3C.REC-xmlschema-2-20041028] for the format of the "lang" 1109 attribute. Added the corresponding section (3.2.6) for the 1110 "duration" attribute. 1111 3. Added the "XML" prefix for each reference to "schema" in the 1112 introduction of section 5. 1113 4. Added the leading sentence "The Security Considerations of 1114 [RFC5730] apply in this document, and this document enhances 1115 these considerations." to section 8. 1116 5. Added the sentence 'The possible set of "name" values, by 1117 event type, can be discovered / negotiated out of band to EPP 1118 or using a separate EPP extension designed to provide server 1119 policy information to the client.' to the description of the 1120 "name" attribute. 1121 6. Added a description of how to create the , 1122 , and values using ABNF. 1123 5. Updates based on feedback from Alexey Melnikov during the IESG 1124 review: 1126 1. Added a description of "whitespace" to section 1.1. 1127 2. Added a description of the usage of the user agent 1128 information in section 4.1. 1129 6. Updates based on feedback from Benjamin Kaduk during the IESG 1130 review: 1132 1. Added "A newer version of the extension is expected to use 1133 an XML namespace with a higher version number than the prior 1134 versions." to the first paragraph of section 2. 1135 2. In section 3.1, replace the sentence "There MAY be multiple 1136 events returned that provide information for the client to 1137 address." with "The element is contained in 1138 a list of one or more elements in the 1139 element, so there MAY be multiple 1140 events returned that provide information for the client to 1141 address." 1142 3. In section 3.1, for the "exDate" attribute, replace the 1143 sentence "At expiry there MAY be an error to connect or MAY 1144 be an error to login." with "At expiry there MAY be a 1145 connection failure or MAY be a login failure." and a similar 1146 change to the following sentence. 1147 4. In section 3.1, replace the description of the "cipher" type 1148 and the "tlsProtocol" type. 1150 5. In section 3.1, add a sentence that the "exDate" attribute 1151 MUST be set for the "password" type and the "certificate" 1152 type. 1153 6. Updates the dates by replacing 2018 with 2020. 1154 7. In section 3.2, update the MUST override sentences for the 1155 and the elements. 1156 8. In section 4.1, update "OPTIONAL client user agent" with 1157 "OPTIONAL client user agent information" for the description 1158 of the element. 1159 9. In section 4.1, replace "MUST only be used" to "MUST only be 1160 set" for the and elements. 1161 10. Updated references of "x86_64 Mac OS X 10.11.6" to "x86_64 1162 Mac OS X 10.15.2". 1163 11. In section 4.1, replace "MUST be included in the response 1164 based on both of the following conditions" with "MUST be 1165 included in the response when both of the following 1166 conditions hold". 1167 12. In section 4.1, update the "exDate" for the "password" 1168 security event error to be "2020-03-24T22:00:00.0Z" so that 1169 it's prior to the date 2020-03-25 reference previously. 1170 13. In section 8, add the sentence "The server returning of 1171 security events to unauthenticated users needs to take into 1172 account the security/privacy issues of returning information 1173 to potential attackers." to the end of the last paragraph. 1174 14. In section 8, change "minimum length beyond 6 characters" to 1175 "minimum length greater than 6 characters". 1176 15. In section 8, add the sentence "The user agent information 1177 represents the client system of a system-to-system 1178 interface, so the user agent information MUST NOT provide 1179 any ability to track individual users or classes of users." 1181 A.13. Change from REGEXT 08 to REGEXT 09 1183 1. Based on feedback from Barry Leiba in responding to Benjamin 1184 Kaduk's discuss item, changed "It is recommended that the plain 1185 text..." to "It is RECOMMENDED that the plain text..." and "If 1186 non-ASCII characters are supported with the plain text password, 1187 then use a standard for passwords with international characters, 1188 such as the OpaqueString PRECIS profile in [RFC8265]." to "If 1189 non-ASCII characters are supported with the plain text password, 1190 then use a standard for passwords with international characters; 1191 the OpaqueString PRECIS profile in [RFC8265] is recommended in 1192 the absence of other considerations." 1194 A.14. Change from REGEXT 09 to REGEXT 10 1196 1. Based on feedback from Benjamin Kaduk, added the sentence "EPP 1197 [RFC5730] includes a maximum password length of 16 characters 1198 that inhibits implementing stronger password security policies 1199 with higher entropy." to the Introduction. 1201 Authors' Addresses 1203 James Gould 1204 VeriSign, Inc. 1205 12061 Bluemont Way 1206 Reston, VA 20190 1207 US 1209 Email: jgould@verisign.com 1210 URI: http://www.verisign.com 1212 Matthew Pozun 1213 VeriSign, Inc. 1214 12061 Bluemont Way 1215 Reston, VA 20190 1216 US 1218 Email: mpozun@verisign.com 1219 URI: http://www.verisign.com