idnits 2.17.1 draft-ietf-regext-login-security-06.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 (November 19, 2019) is 1613 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 845 Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 3 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: May 22, 2020 November 19, 2019 7 Login Security Extension for the Extensible Provisioning Protocol (EPP) 8 draft-ietf-regext-login-security-06 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 May 22, 2020. 38 Copyright Notice 40 Copyright (c) 2019 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 . . . . . . . . . . . . . . . . . . . . . . . . 2 56 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 57 2. Migrating to Newer Versions of This Extension . . . . . . . . 3 58 3. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 4 59 3.1. Event . . . . . . . . . . . . . . . . . . . . . . . . . . 4 60 3.2. "[LOGIN-SECURITY]" Password . . . . . . . . . . . . . . . 5 61 3.3. Dates and Times . . . . . . . . . . . . . . . . . . . . . 6 62 4. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 6 63 4.1. EPP Command . . . . . . . . . . . . . . . . . . . 6 64 5. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 14 65 5.1. Login Security Extension Schema . . . . . . . . . . . . . 14 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 67 6.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 16 68 6.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 17 69 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 17 70 7.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 18 71 8. Security Considerations . . . . . . . . . . . . . . . . . . . 18 72 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 19 73 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 19 74 10.1. Normative References . . . . . . . . . . . . . . . . . . 19 75 10.2. Informative References . . . . . . . . . . . . . . . . . 19 76 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 20 77 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 20 78 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 20 79 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 20 80 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 20 81 A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 20 82 A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 20 83 A.6. Change from REGEXT 01 to REGEXT 02 . . . . . . . . . . . 21 84 A.7. Change from REGEXT 02 to REGEXT 03 . . . . . . . . . . . 21 85 A.8. Change from REGEXT 03 to REGEXT 04 . . . . . . . . . . . 22 86 A.9. Change from REGEXT 04 to REGEXT 05 . . . . . . . . . . . 22 87 A.10. Change from REGEXT 05 to REGEXT 06 . . . . . . . . . . . 22 88 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 23 90 1. Introduction 92 This document describes an Extensible Provisioning Protocol (EPP) 93 extension for enhancing the security of the EPP login command in EPP 94 [RFC5730]. The enhancements include supporting longer passwords (or 95 passphrases) than the 16-character maximum and providing a list of 96 security events in the login response. The password (current and 97 new) in EPP [RFC5730] can be overridden by the password included in 98 the extension to extend past the 16-character maximum. The security 99 events supported include: password expiry, client certificate expiry, 100 insecure cipher, insecure TLS protocol, new pasword complexity, login 101 security statistical warning, and a custom event. The attributes 102 supported by the security events include identifying the event type 103 or sub-type, indicating the security level of warning or error, a 104 future or past-due expiration date, the value that resulted in the 105 event, the duration of the statistical event, and a free-form 106 description with an optional language. 108 1.1. Conventions Used in This Document 110 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 111 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 112 "OPTIONAL" in this document are to be interpreted as described in BCP 113 14 [RFC2119] [RFC8174] when, and only when, they appear in all 114 capitals, as shown here. 116 XML is case sensitive. Unless stated otherwise, XML specifications 117 and examples provided in this document MUST be interpreted in the 118 character case presented in order to develop a conforming 119 implementation. 121 In examples, "C:" represents lines sent by a protocol client and "S:" 122 represents lines returned by a protocol server. Indentation and 123 white space in examples are provided only to illustrate element 124 relationships and are not a required feature of this protocol. 126 "loginSec-1.0" is used as an abbreviation for 127 "urn:ietf:params:xml:ns:epp:loginSec-1.0". The XML namespace prefix 128 "loginSec" is used, but implementations MUST NOT depend on it and 129 instead employ a proper namespace-aware XML parser and serializer to 130 interpret and output the XML documents. 132 2. Migrating to Newer Versions of This Extension 134 Servers which implement this extension SHOULD provide a way for 135 clients to progressively update their implementations when a new 136 version of the extension is deployed. 138 Servers SHOULD (for a temporary migration period up to server policy) 139 provide support for older versions of the extension in parallel to 140 the newest version, and allow clients to select their preferred 141 version via the element of the command. 143 If a client requests multiple versions of the extension at login, 144 then, when preparing responses to commands which do not include 145 extension elements, the server SHOULD only include extension elements 146 in the namespace of the newest version of the extension requested by 147 the client. 149 When preparing responses to commands which do include extension 150 elements, the server SHOULD only include extension elements for the 151 extension versions present in the command. 153 3. Object Attributes 155 This extension adds additional elements to [RFC5730] login command 156 and response. Only those new elements are described here. 158 3.1. Event 160 A security event, using the element, represents 161 either a warning or error identified by the server after the client 162 has connected and submitted the login command. There MAY be multiple 163 events returned that provide information for the client to address. 164 The MAY include a free-form description. All of the 165 security events use a consistent set of attributes, where the exact 166 set of applicable attributes is based on the event type. The 167 supported set of element attributes include: 169 "type": A REQUIRED attribute that defines the type of security 170 event. The enumerated list of "type" values includes: 172 "password": Identifies a password expiry event, where the 173 password expires in the future or has expired based on the 174 "exDate" date and time. 175 "certificate": Identifies a client certificate expiry event, 176 where the client certificate will expire at the "exDate" date 177 and time. 178 "cipher": Identifies the use of an insecure or deprecated TLS 179 cipher suite. 180 "tlsProtocol": Identifies the use of an insecure or deprecated 181 TLS protocol. 182 "newPW": The new password does not meet the server password 183 complexity requirements. 184 "stat": Provides a login security statistical warning that MUST 185 set the "name" attribute to the name of the statistic sub- 186 type. 187 "custom": Custom event type that MUST set the "name" attribute 188 with the custom event type name. 189 "name": Used to define a sub-type when the "type" attribute is not 190 "custom" or the full type name when the "type" attribute is 191 "custom". The "name" attribute MUST be set when the "type" 192 attribute is "stat" or "custom". 193 "level": Defines the level of the event as either "warning" for a 194 warning event that needs action, or "error" for an error event 195 that requires immediate action. 196 "exDate": Contains the date and time that a "warning" level has or 197 will become an "error" level. At expiry there MAY be an error to 198 connect or MAY be an error to login. An example is an expired 199 certificate that will result in an error to connect or an expired 200 password that may result in a failed login. 201 "value": Identifies the value that resulted in the login security 202 event. An example is the negotiated insecure cipher suite or the 203 negotiated insecure TLS protocol. 204 "duration": Defines the duration that a statistical event is 205 associated with, ending when the login command was received. The 206 format of the duration is defined by the duration primitive 207 datatype in [W3C.REC-xmlschema-2-20041028]. 208 "lang": Identifies the negotiated language of the free-form 209 description. The default is "en" (English). 211 Example login security event for password expiration, where the 212 current date is 2018-03-25: 214 219 Password expiration soon 220 222 Example login security event for identifying 100 failed logins over 223 the last day, using the "stat" sub-type of "failedLogins": 225 231 Excessive invalid daily logins 232 234 3.2. "[LOGIN-SECURITY]" Password 236 The element MUST override the [RFC5730] element 237 only if the contains the predefined value of "[LOGIN-SECURITY]", 238 which is a constant value for the server to use the 239 element for the password. Similarly, the element 240 MUST override the [RFC5730] element only if the 241 contains the predefined value of "[LOGIN-SECURITY]", which is a 242 constant value for the server to use the element for 243 the new password. The "[LOGIN-SECURITY]" pre-defined string MUST be 244 supported by the server for the client to explicitly indicate to the 245 server whether to use element in place of the [RFC5730] 246 element or to use the in place of the [RFC5730] 247 element. The server MUST NOT allow the client to set the 248 password to the value "[LOGIN-SECURITY]". 250 3.3. Dates and Times 252 Date and time attribute values MUST be represented in Universal 253 Coordinated Time (UTC) using the Gregorian calendar. The extended 254 date-time form using upper case "T" and "Z" characters defined in 255 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 256 values, as XML Schema does not support truncated date-time forms or 257 lower case "T" and "Z" characters. 259 4. EPP Command Mapping 261 A detailed description of the EPP syntax and semantics can be found 262 in the EPP core protocol specification [RFC5730]. 264 4.1. EPP Command 266 This extension defines additional elements to extend the EPP 267 command and response to be used in conjunction with [RFC5730]. 269 The EPP command is used to establish a session with an EPP 270 server. This extension overrides the password that is passed with 271 the [RFC5730] or the element as defined in Section 3.2. 272 A element is sent along with the [RFC5730] 273 command and MUST contain at least one of the following child 274 elements: 276 : OPTIONAL client user agent that identifies the 277 client application software, technology, and operating system 278 used by the server to identify functional or security 279 constraints, current security issues, and potential future 280 functional or security issues for the client. The 281 element MUST contain at least one of the 282 following child elements: 284 : OPTIONAL name of the client application software 285 with version if available, such as the name of the client SDK 286 "EPP SDK 1.0.0". 287 : OPTIONAL technology used for the client 288 software with version if available, such as "Java 11.0.2". 289 : OPTIONAL client operating system used with 290 version if available, such as "x86_64 Mac OS X 10.11.6". 291 : OPTIONAL plain text password that is case sensitive, 292 has a minimum length of 6 characters, and has a maximum length 293 that is up to server policy. All leading and trailing whitespace 294 is removed, and all internal contiguous whitespace that includes 295 #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20 296 (space) is replaced with a single #x20 (space). This element 297 MUST only be used if the [RFC5730] element is set to the 298 "[LOGIN-SECURITY]" value. 299 : OPTIONAL plain text new password that is case 300 sensitive, has a minimum length of 6 characters, and has a 301 maximum length that is up to server policy. All leading and 302 trailing whitespace is removed, and all internal contiguous 303 whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage 304 return), and #x20 (space) is replaced with a single #x20 (space). 305 This element MUST only be used if the [RFC5730] element 306 is set to the "[LOGIN-SECURITY]" value. 308 Example login command that uses the element instead of 309 the [RFC5730] element to establish the session and includes the 310 element: 312 C: 313 C: 314 C: 315 C: 316 C: ClientX 317 C: [LOGIN-SECURITY] 318 C: 319 C: 1.0 320 C: en 321 C: 322 C: 323 C: urn:ietf:params:xml:ns:obj1 324 C: urn:ietf:params:xml:ns:obj2 325 C: urn:ietf:params:xml:ns:obj3 326 C: 327 C: urn:ietf:params:xml:ns:epp:loginSec-1.0 328 C: 329 C: 330 C: 331 C: 332 C: 335 C: 336 C: EPP SDK 1.0.0 337 C: Java 11.0.2 338 C: x86_64 Mac OS X 10.11.6 339 C: 340 C: this is a long password 341 C: 342 C: 343 C: ABC-12345 344 C: 345 C: 346 Example login command that uses the element instead of 347 the [RFC5730] element to establish the session, and uses the 348 element instead of the [RFC5730] element to 349 set the new password: 351 C: 352 C: 353 C: 354 C: 355 C: ClientX 356 C: [LOGIN-SECURITY] 357 C: [LOGIN-SECURITY] 358 C: 359 C: 1.0 360 C: en 361 C: 362 C: 363 C: urn:ietf:params:xml:ns:obj1 364 C: urn:ietf:params:xml:ns:obj2 365 C: urn:ietf:params:xml:ns:obj3 366 C: 367 C: urn:ietf:params:xml:ns:epp:loginSec-1.0 368 C: 369 C: 370 C: 371 C: 372 C: 375 C: this is a long password 376 C: 377 C: new password that is still long 378 C: 379 C: 380 C: 381 C: ABC-12345 382 C: 383 C: 384 Example login command that uses the [RFC5730] element to 385 establish the session, and uses the element instead 386 of the [RFC5730] element to set the new password: 388 C: 389 C: 390 C: 391 C: 392 C: ClientX 393 C: shortpassword 394 C: [LOGIN-SECURITY] 395 C: 396 C: 1.0 397 C: en 398 C: 399 C: 400 C: urn:ietf:params:xml:ns:obj1 401 C: urn:ietf:params:xml:ns:obj2 402 C: urn:ietf:params:xml:ns:obj3 403 C: 404 C: urn:ietf:params:xml:ns:epp:loginSec-1.0 405 C: 406 C: 407 C: 408 C: 409 C: 412 C: new password that is still long 413 C: 414 C: 415 C: 416 C: ABC-12345 417 C: 418 C: 420 Upon a completed login command (success or failed), the extension 421 MUST be included in the response based on both of the following 422 conditions: 424 Client supports extension: The client supports the extension based 425 on the element of the command. 426 At least one login security event: The server has identified at 427 least one login security event to communicate to the client. 429 The extension to the EPP response uses the 430 element that contains the following child elements: 432 : One or more elements defined in 433 Section 3.1. 435 Example EPP response to a successful login command on 2018-03-25, 436 where the password will expire in a week: 438 S: 439 S: 440 S: 441 S: 442 S: Command completed successfully 443 S: 444 S: 445 S: 448 S: 453 S: Password expiring in a week 454 S: 455 S: 456 S: 457 S: 458 S: ABC-12345 459 S: 54321-XYZ 460 S: 461 S: 462 S: 463 Example EPP response to a failed login command where the password has 464 expired and the new password does not meet the server complexity 465 requirements: 467 S: 468 S: 469 S: 470 S: 471 S: Authentication error 472 S: 473 S: 474 S: 477 S: 481 S: Password has expired 482 S: 483 S: 486 S: New password does not meet complexity requirements 487 S: 488 S: 489 S: 490 S: 491 S: ABC-12345 492 S: 54321-XYZ 493 S: 494 S: 495 S: 497 Example EPP response to a successful login command where there is a 498 set of login security events: 500 S: 501 S: 502 S: 503 S: 504 S: Command completed successfully 505 S: 506 S: 507 S: 510 S: 515 S: Password expiration soon 516 S: 517 S: 521 S: 525 S: Non-PFS Cipher negotiated 526 S: 527 S: 531 S: Insecure TLS protocol negotiated 532 S: 533 S: 539 S: Excessive invalid daily logins 540 S: 541 S: 545 S: A custom login security event occured 546 S: 547 S: 548 S: 549 S: 550 S: ABC-12345 551 S: 54321-XYZ 552 S: 553 S: 554 S: 556 5. Formal Syntax 558 One schema is presented here that is the EPP Login Security Extension 559 schema. 561 The formal syntax presented here is a complete schema representation 562 of the object mapping suitable for automated validation of EPP XML 563 instances. The BEGIN and END tags are not part of the schema; they 564 are used to note the beginning and ending of the schema for URI 565 registration purposes. 567 5.1. Login Security Extension Schema 569 BEGIN 570 571 577 580 581 582 583 Extensible Provisioning Protocol v1.0 584 Login Security Extension Schema. 585 586 587 588 591 592 593 595 597 599 600 601 602 603 605 606 607 608 609 610 612 614 616 617 618 620 622 623 625 626 627 628 630 631 632 635 636 637 638 639 640 641 643 645 647 649 651 654 656 657 658 659 662 663 664 665 666 667 668 669 670 671 672 673 676 677 678 679 680 681 682 685 686 END 688 6. IANA Considerations 690 6.1. XML Namespace 692 This document uses URNs to describe XML namespaces and XML schemas 693 conforming to a registry mechanism described in [RFC3688]. The 694 following URI assignment is requested of IANA: 696 Registration request for the loginSec namespace: 698 URI: urn:ietf:params:xml:ns:epp:loginSec-1.0 699 Registrant Contact: IESG 700 XML: None. Namespace URIs do not represent an XML specification. 702 Registration request for the loginSec XML schema: 704 URI: urn:ietf:params:xml:schema:epp:loginSec-1.0 705 Registrant Contact: IESG 706 XML: See the "Formal Syntax" section of this document. 708 6.2. EPP Extension Registry 710 The EPP extension described in this document should be registered by 711 the IANA in the EPP Extension Registry described in [RFC7451]. The 712 details of the registration are as follows: 714 Name of Extension: "Login Security Extension for the Extensible 715 Provisioning Protocol (EPP)" 717 Document status: Standards Track 719 Reference: (insert reference to RFC version of this document) 721 Registrant Name and Email Address: IESG, 723 TLDs: Any 725 IPR Disclosure: None 727 Status: Active 729 Notes: None 731 7. Implementation Status 733 Note to RFC Editor: Please remove this section and the reference to 734 RFC 7942 [RFC7942] before publication. 736 This section records the status of known implementations of the 737 protocol defined by this specification at the time of posting of this 738 Internet-Draft, and is based on a proposal described in RFC 7942 739 [RFC7942]. The description of implementations in this section is 740 intended to assist the IETF in its decision processes in progressing 741 drafts to RFCs. Please note that the listing of any individual 742 implementation here does not imply endorsement by the IETF. 743 Furthermore, no effort has been spent to verify the information 744 presented here that was supplied by IETF contributors. This is not 745 intended as, and must not be construed to be, a catalog of available 746 implementations or their features. Readers are advised to note that 747 other implementations may exist. 749 According to RFC 7942 [RFC7942], "this will allow reviewers and 750 working groups to assign due consideration to documents that have the 751 benefit of running code, which may serve as evidence of valuable 752 experimentation and feedback that have made the implemented protocols 753 more mature. It is up to the individual working groups to use this 754 information as they see fit". 756 7.1. Verisign EPP SDK 758 Organization: Verisign Inc. 760 Name: Verisign EPP SDK 762 Description: The Verisign EPP SDK includes both a full client 763 implementation and a full server stub implementation of draft-ietf- 764 regext-login-security. 766 Level of maturity: Development 768 Coverage: All aspects of the protocol are implemented. 770 Licensing: GNU Lesser General Public License 772 Contact: jgould@verisign.com 774 URL: https://www.verisign.com/en_US/channel-resources/domain- 775 registry-products/epp-sdks 777 8. Security Considerations 779 The extension leaves the password ( element) and new password 780 ( element) minimum length beyond 6 characters and the maximum 781 length up to sever policy. The server SHOULD enforce minimum and 782 maximum length requirements that are appropriate for their operating 783 environment. One example of a guideline for password length policies 784 can be found in section 5 of NIST Special Publication 800-63B [1]. 786 The client SHOULD NOT decrease the security of a new password by 787 decreasing the length of the current password. For example, a client 788 with a 20 character password set using the extension, should not use 789 the login command in [RFC5730] without using the extension, to set a 790 new password that is less than or equal to 16 characters. 792 The extension provides an extensible list of login security events to 793 inform clients of connection and login warnings and errors. 795 9. Acknowledgements 797 The authors wish to thank the following persons for their feedback 798 and suggestions: 800 o Martin Casanova 801 o Scott Hollenbeck 802 o Patrick Mevzek 803 o Joseph Yee 805 10. References 807 10.1. Normative References 809 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 810 Requirement Levels", BCP 14, RFC 2119, 811 DOI 10.17487/RFC2119, March 1997, 812 . 814 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 815 DOI 10.17487/RFC3688, January 2004, 816 . 818 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 819 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 820 . 822 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 823 Code: The Implementation Status Section", BCP 205, 824 RFC 7942, DOI 10.17487/RFC7942, July 2016, 825 . 827 [W3C.REC-xmlschema-2-20041028] 828 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 829 Second Edition", World Wide Web Consortium Recommendation 830 REC-xmlschema-2-20041028, October 2004, 831 . 833 10.2. Informative References 835 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 836 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 837 February 2015, . 839 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 840 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 841 May 2017, . 843 10.3. URIs 845 [1] https://pages.nist.gov/800-63-3/sp800-63b.html 847 Appendix A. Change History 849 A.1. Change from 00 to 01 851 1. Based on the feedback from Patrick Mevzek and a proposal from 852 Scott Hollenbeck, changed the minimum length of the password from 853 8 to 6, revised the description of the password, and added text 854 in the Security Considerations section for the server password 855 length policy. 857 A.2. Change from 01 to 02 859 1. Changed the XML namespace from urn:ietf:params:xml:ns:loginSec- 860 0.3 to urn:ietf:params:xml:ns:epp:loginSec-0.3, and changed the 861 XML schema registration from urn:ietf:params:xml:ns:loginSec-0.3 862 to urn:ietf:params:xml:schema:epp:loginSec-0.3 based on a request 863 from IANA with draft-ietf-regext-allocation-token. 865 A.3. Change from 02 to 03 867 1. Updates based on the review by Patrick Mevzek, that include: 869 1. Fix the inconsistent case for newPW, that required a global 870 change in the draft text and an update to the XML schema to 871 "urn:ietf:params:xml:ns:loginSec-0.3". 872 2. Changed "contains the following child elements" to "MUST 873 contain at least one of the following child elements", 874 section "EPP Command" to ensure that an empty 875 element is not passed. 876 3. Add "The client SHOULD NOT decrease the security of a new 877 password by decreasing the length of the current password." 878 along with an example to the "Security Considerations" 879 section. 881 A.4. Change from 03 to REGEXT 00 883 1. Changed to regext working group draft by changing draft-gould- 884 regext-login-security to draft-ietf-regext-login-security. 886 A.5. Change from REGEXT 00 to REGEXT 01 888 1. Changed the element to be structured with 889 the , , and sub- 890 elements. This was based on the feedback from Martin Casanova. 892 This resulted in the need to change the XML namespace from 893 urn:ietf:params:xml:ns:epp:loginSec-0.3 to 894 urn:ietf:params:xml:ns:epp:loginSec-0.4. 896 A.6. Change from REGEXT 01 to REGEXT 02 898 1. Updated the Implementation Status section from "TBD" to include 899 the Verisign EPP SDK implementation. 901 A.7. Change from REGEXT 02 to REGEXT 03 903 1. Revised the description of the "duration" attribute to clarify 904 that it ends when the login command was received and to clarify 905 the format, based on the feedback from Martin Casanova. 906 2. Revised the sentence 'Upon a completed login command (success or 907 failed), the extension MUST be included in the response based on 908 the following conditions:' to 'Upon a completed login command 909 (success or failed), the extension MUST be included in the 910 response based on both of the following conditions:' based on the 911 feedback from Patrick Mevzek. 912 3. Updates based on the review by Joseph Yee, that include: 914 1. Revised the description of the "name" 915 attribute read 'Used to define a sub-type when the "type" 916 attribute is not "custom" or the full type name when the 917 "type" attribute is "custom"'. The definition of the "stat" 918 type was updated to 'Provides a login security statistical 919 warning that MUST set the "name" attribute to the name of the 920 statistic.' 921 2. Added the following sentence 'The server MUST NOT allow the 922 client to set the password to the value "[LOGIN-SECURITY]".' 923 to address the corner case where the constant is used as the 924 password. 925 3. Revised the description of the element 926 to read 'The element MUST contain at 927 least one of the following child elements:'. 928 4. Revised the description of the to match the 929 child elements that can be passed, by changing "client software" 930 to "client application software" and change "language" to 931 "technology". 932 5. Changed the XML namespace from 933 urn:ietf:params:xml:ns:epp:loginSec-0.4 to 934 urn:ietf:params:xml:ns:epp:loginSec-1.0. 936 A.8. Change from REGEXT 03 to REGEXT 04 938 Updates based on the review by Joseph Yee, that include: 940 1. Update the definition of the "stat" security event type to 941 reference sub-type to match the language for the "name" 942 attribute. 943 2. Added the sentence 'The "name" attribute MUST be set when the 944 "type" attribute is "stat" or "custom".' to the definition of the 945 "name" attribute for clarity. 946 3. Update the definition of the "userAgentType" in the XML schema to 947 require at least one sub-element using a element. 949 A.9. Change from REGEXT 04 to REGEXT 05 951 Updates based on the review by Barry Leiba, that include: 953 1. In section 1.1, updated to use BCP 14 boilerplate and references 954 as defined in RFC 8174. 955 2. In section 1.1, change "REQUIRED" to "required". 956 3. Keep the "Migration to Newer Versions of This Extension" section 957 by removing the note for removal to the RFC Editor. 958 4. In section 3.1, change "MAY be multiple events returned that 959 provides information" to "MAY be multiple events returned that 960 provide information". 961 5. In section 3.1, change "free form" to "free-form". 962 6. In section 3.1, change "The enumerated list of "type" values 963 include:" to "The enumerated list of "type" values includes:". 964 7. In section 3.1, change "Identifies the language of the free-form 965 description if the negotiated language is something other than 966 the default value of "en" (English)." to "Identifies the 967 negotiated language of the free-form description. The default is 968 "en" (English). 969 8. In section 3.1, change example description from "Example login 970 security event for a password expiring in a week:" to "Example 971 login security event for password expiration, where the current 972 date is 2018-03-25:". 973 9. In section 4.1, change "Example EPP response to a successful 974 login command where the password will expire in a week:" to 975 "Example EPP response to a successful login command on 976 2018-03-25, where the password will expire in a week:". 978 A.10. Change from REGEXT 05 to REGEXT 06 980 Updates based on the review by Brian Carpenter, that include: 982 1. In section 1, change the references to RFC 5730 to use links. 984 2. In section 2, change "(for a temporary migration period)" to 985 "(for a temporary migration period up to server policy)". 987 Authors' Addresses 989 James Gould 990 VeriSign, Inc. 991 12061 Bluemont Way 992 Reston, VA 20190 993 US 995 Email: jgould@verisign.com 996 URI: http://www.verisign.com 998 Matthew Pozun 999 VeriSign, Inc. 1000 12061 Bluemont Way 1001 Reston, VA 20190 1002 US 1004 Email: mpozun@verisign.com 1005 URI: http://www.verisign.com