idnits 2.17.1 draft-ietf-regext-login-security-02.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 (June 25, 2019) is 1764 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 829 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: December 27, 2019 June 25, 2019 7 Login Security Extension for the Extensible Provisioning Protocol (EPP) 8 draft-ietf-regext-login-security-02 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 http://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 December 27, 2019. 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 (http://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 . . . . . . . . . . . . . . . . . . . . . . . . . . 19 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 86 1. Introduction 88 This document describes an Extensible Provisioning Protocol (EPP) 89 extension for enhancing the security of the EPP login command in EPP 90 RFC 5730. The enhancements include supporting longer passwords (or 91 passphrases) than the 16-character maximum and providing a list of 92 security events in the login response. The password (current and 93 new) in EPP RFC 5730 can be overridden by the password included in 94 the extension to extend past the 16-character maximum. The security 95 events supported include: password expiry, client certificate expiry, 96 insecure cipher, insecure TLS protocol, new pasword complexity, login 97 security statistical warning, and a custom event. The attributes 98 supported by the security events include identifying the event type 99 or sub-type, indicating the security level of warning or error, a 100 future or past-due expiration date, the value that resulted in the 101 event, the duration of the statistical event, and a free-form 102 description with an optional language. 104 1.1. Conventions Used in This Document 106 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 107 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 108 document are to be interpreted as described in RFC 2119 [RFC2119]. 110 XML is case sensitive. Unless stated otherwise, XML specifications 111 and examples provided in this document MUST be interpreted in the 112 character case presented in order to develop a conforming 113 implementation. 115 In examples, "C:" represents lines sent by a protocol client and "S:" 116 represents lines returned by a protocol server. Indentation and 117 white space in examples are provided only to illustrate element 118 relationships and are not a REQUIRED feature of this protocol. 120 "loginSec-0.4" is used as an abbreviation for 121 "urn:ietf:params:xml:ns:epp:loginSec-0.4". The XML namespace prefix 122 "loginSec" is used, but implementations MUST NOT depend on it and 123 instead employ a proper namespace-aware XML parser and serializer to 124 interpret and output the XML documents. 126 2. Migrating to Newer Versions of This Extension 128 (Note to RFC Editor: remove this section before publication as an 129 RFC.) 131 Servers which implement this extension SHOULD provide a way for 132 clients to progressively update their implementations when a new 133 version of the extension is deployed. 135 Servers SHOULD (for a temporary migration period) provide support for 136 older versions of the extension in parallel to the newest version, 137 and allow clients to select their preferred version via the 138 element of the command. 140 If a client requests multiple versions of the extension at login, 141 then, when preparing responses to commands which do not include 142 extension elements, the server SHOULD only include extension elements 143 in the namespace of the newest version of the extension requested by 144 the client. 146 When preparing responses to commands which do include extension 147 elements, the server SHOULD only include extension elements for the 148 extension versions present in the command. 150 3. Object Attributes 152 This extension adds additional elements to [RFC5730] login command 153 and response. Only those new elements are described here. 155 3.1. Event 157 A security event, using the element, represents 158 either a warning or error identified by the server after the client 159 has connected and submitted the login command. There MAY be multiple 160 events returned that provides information for the client to address. 161 The MAY include a free form description. All of the 162 security events use a consistent set of attributes, where the exact 163 set of applicable attributes is based on the event type. The 164 supported set of element attributes include: 166 "type": A REQUIRED attribute that defines the type of security 167 event. The enumerated list of "type" values include: 169 "password": Identifies a password expiry event, where the 170 password expires in the future or has expired based on the 171 "exDate" date and time. 172 "certificate": Identifies a client certificate expiry event, 173 where the client certificate will expire at the "exDate" date 174 and time. 175 "cipher": Identifies the use of an insecure or deprecated TLS 176 cipher suite. 177 "tlsProtocol": Identifies the use of an insecure or deprecated 178 TLS protocol. 179 "newPW": The new password does not meet the server password 180 complexity requirements. 181 "stat": Provides a login security statistical warning that MUST 182 set the "name" of the statistic. 183 "custom": Custom event type that MUST set the "name" attribute 184 with the custom event type name. 185 "name": Used to define a sub-type or the type name when the "type" 186 attribute is "custom". 187 "level": Defines the level of the event as either "warning" for a 188 warning event that needs action, or "error" for an error event 189 that requires immediate action. 190 "exDate": Contains the date and time that a "warning" level has or 191 will become an "error" level. At expiry there MAY be an error to 192 connect or MAY be an error to login. An example is an expired 193 certificate that will result in a error to connect or an expired 194 password that may result in a failed login. 195 "value": Identifies the value that resulted in the login security 196 event. An example is the negotiated insecure cipher suite or the 197 negotiated insecure TLS protocol. 198 "duration": Defines the duration that a statistical event is 199 associated with. 200 "lang": Identifies the language of the free form description if the 201 negotiated language is something other than the default value of 202 "en" (English). 204 Example login security event for a password expiring in a week: 206 211 Password expiration soon 212 214 Example login security event for identifying 100 failed logins over 215 the last day, using the "stat" sub-type of "failedLogins": 217 223 Excessive invalid daily logins 224 226 3.2. "[LOGIN-SECURITY]" Password 228 The element MUST override the [RFC5730] element 229 only if the contains the predefined value of "[LOGIN-SECURITY]", 230 which is a constant value for the server to use the 231 element for the password. Similarly, the element 232 MUST override the [RFC5730] element only if the 233 contains the predefined value of "[LOGIN-SECURITY]", which is a 234 constant value for the server to use the element for 235 the new password. The "[LOGIN-SECURITY]" pre-defined string MUST be 236 supported by the server for the client to explicitly indicate to the 237 server whether to use element in place of the [RFC5730] 238 element or to use the in place of the [RFC5730] 239 element. 241 3.3. Dates and Times 243 Date and time attribute values MUST be represented in Universal 244 Coordinated Time (UTC) using the Gregorian calendar. The extended 245 date-time form using upper case "T" and "Z" characters defined in 246 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 247 values, as XML Schema does not support truncated date-time forms or 248 lower case "T" and "Z" characters. 250 4. EPP Command Mapping 252 A detailed description of the EPP syntax and semantics can be found 253 in the EPP core protocol specification [RFC5730]. 255 4.1. EPP Command 257 This extension defines additional elements to extend the EPP 258 command and response to be used in conjunction with [RFC5730]. 260 The EPP command is used to establish a session with an EPP 261 server. This extension overrides the password that is passed with 262 the [RFC5730] or the element as defined in Section 3.2. 263 A element is sent along with the [RFC5730] 264 command and MUST contain at least one of the following child 265 elements: 267 : OPTIONAL client user agent that identifies the 268 client software, language, and operating system used by the 269 server to identify functional or security constraints, current 270 security issues, and potential future functional or security 271 issues for the client. The element contains 272 the following child elements: 274 : OPTIONAL name of the client application software 275 with version if available, such as the name of the client SDK 276 "EPP SDK 1.0.0". 277 : OPTIONAL technology used for the client 278 software with version if available, such as "Java 11.0.2". 279 : OPTIONAL client operating system used with 280 version if available, such as "x86_64 Mac OS X 10.11.6". 281 : OPTIONAL plain text password that is case sensitive, 282 has a minimum length of 6 characters, and has a maximum length 283 that is up to server policy. All leading and trailing whitespace 284 is removed, and all internal contiguous whitespace that includes 285 #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20 286 (space) is replaced with a single #x20 (space). This element 287 MUST only be used if the [RFC5730] element is set to the 288 "[LOGIN-SECURITY]" value. 289 : OPTIONAL plain text new password that is case 290 sensitive, has a minimum length of 6 characters, and has a 291 maximum length that is up to server policy. All leading and 292 trailing whitespace is removed, and all internal contiguous 293 whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage 294 return), and #x20 (space) is replaced with a single #x20 (space). 295 This element MUST only be used if the [RFC5730] element 296 is set to the "[LOGIN-SECURITY]" value. 298 Example login command that uses the element instead of 299 the [RFC5730] element to establish the session and includes the 300 element: 302 C: 303 C: 304 C: 305 C: 306 C: ClientX 307 C: [LOGIN-SECURITY] 308 C: 309 C: 1.0 310 C: en 311 C: 312 C: 313 C: urn:ietf:params:xml:ns:obj1 314 C: urn:ietf:params:xml:ns:obj2 315 C: urn:ietf:params:xml:ns:obj3 316 C: 317 C: urn:ietf:params:xml:ns:epp:loginSec-0.4 318 C: 319 C: 320 C: 321 C: 322 C: 325 C: 326 C: EPP SDK 1.0.0 327 C: Java 11.0.2 328 C: x86_64 Mac OS X 10.11.6 329 C: 330 C: this is a long password 331 C: 332 C: 333 C: ABC-12345 334 C: 335 C: 336 Example login command that uses the element instead of 337 the [RFC5730] element to establish the session, and uses the 338 element instead of the [RFC5730] element to 339 set the new password: 341 C: 342 C: 343 C: 344 C: 345 C: ClientX 346 C: [LOGIN-SECURITY] 347 C: [LOGIN-SECURITY] 348 C: 349 C: 1.0 350 C: en 351 C: 352 C: 353 C: urn:ietf:params:xml:ns:obj1 354 C: urn:ietf:params:xml:ns:obj2 355 C: urn:ietf:params:xml:ns:obj3 356 C: 357 C: urn:ietf:params:xml:ns:epp:loginSec-0.4 358 C: 359 C: 360 C: 361 C: 362 C: 365 C: this is a long password 366 C: 367 C: new password that is still long 368 C: 369 C: 370 C: 371 C: ABC-12345 372 C: 373 C: 374 Example login command that uses the [RFC5730] element to 375 establish the session, and uses the element instead 376 of the [RFC5730] element to set the new password: 378 C: 379 C: 380 C: 381 C: 382 C: ClientX 383 C: shortpassword 384 C: [LOGIN-SECURITY] 385 C: 386 C: 1.0 387 C: en 388 C: 389 C: 390 C: urn:ietf:params:xml:ns:obj1 391 C: urn:ietf:params:xml:ns:obj2 392 C: urn:ietf:params:xml:ns:obj3 393 C: 394 C: urn:ietf:params:xml:ns:epp:loginSec-0.4 395 C: 396 C: 397 C: 398 C: 399 C: 402 C: new password that is still long 403 C: 404 C: 405 C: 406 C: ABC-12345 407 C: 408 C: 410 Upon a completed login command (success or failed), the extension 411 MUST be included in the response based on the following conditions: 413 Client supports extension: client supports the extension based on 414 the element of the command. 415 At least one login security event: The server has identified at 416 least one login security event to communicate to the client. 418 The extension to the EPP response uses the 419 element that contains the following child elements: 421 : One or more elements defined in 422 Section 3.1. 424 Example EPP response to a successful login command where the password 425 will expire in a week: 427 S: 428 S: 429 S: 430 S: 431 S: Command completed successfully 432 S: 433 S: 434 S: 437 S: 442 S: Password expiring in a week 443 S: 444 S: 445 S: 446 S: 447 S: ABC-12345 448 S: 54321-XYZ 449 S: 450 S: 451 S: 452 Example EPP response to a failed login command where the password has 453 expired and the new password does not meet the server complexity 454 requirements: 456 S: 457 S: 458 S: 459 S: 460 S: Authentication error 461 S: 462 S: 463 S: 466 S: 470 S: Password has expired 471 S: 472 S: 475 S: New password does not meet complexity requirements 476 S: 477 S: 478 S: 479 S: 480 S: ABC-12345 481 S: 54321-XYZ 482 S: 483 S: 484 S: 486 Example EPP response to a successful login command where there is a 487 set of login security events: 489 S: 490 S: 491 S: 492 S: 493 S: Command completed successfully 494 S: 495 S: 496 S: 499 S: 504 S: Password expiration soon 505 S: 506 S: 510 S: 514 S: Non-PFS Cipher negotiated 515 S: 516 S: 520 S: Insecure TLS protocol negotiated 521 S: 522 S: 528 S: Excessive invalid daily logins 529 S: 530 S: 534 S: A custom login security event occured 535 S: 536 S: 537 S: 538 S: 539 S: ABC-12345 540 S: 54321-XYZ 541 S: 542 S: 543 S: 545 5. Formal Syntax 547 One schema is presented here that is the EPP Login Security Extension 548 schema. 550 The formal syntax presented here is a complete schema representation 551 of the object mapping suitable for automated validation of EPP XML 552 instances. The BEGIN and END tags are not part of the schema; they 553 are used to note the beginning and ending of the schema for URI 554 registration purposes. 556 5.1. Login Security Extension Schema 558 BEGIN 559 560 567 570 571 573 574 Extensible Provisioning Protocol v1.0 575 Login Security Extension Schema. 576 578 579 581 584 585 586 588 590 592 594 596 597 598 599 600 602 603 604 606 608 610 611 613 614 616 617 618 621 622 624 625 626 627 628 630 632 634 636 638 640 643 644 645 647 650 651 652 653 654 655 656 657 658 659 660 662 665 666 667 668 669 670 671 674 675 END 677 6. IANA Considerations 679 6.1. XML Namespace 681 This document uses URNs to describe XML namespaces and XML schemas 682 conforming to a registry mechanism described in [RFC3688]. The 683 following URI assignment is requested of IANA: 685 Registration request for the loginSec namespace: 687 URI: urn:ietf:params:xml:ns:epp:loginSec-0.4 688 Registrant Contact: IESG 689 XML: None. Namespace URIs do not represent an XML specification. 691 Registration request for the loginSec XML schema: 693 URI: urn:ietf:params:xml:schema:epp:loginSec-0.4 694 Registrant Contact: IESG 695 XML: See the "Formal Syntax" section of this document. 697 6.2. EPP Extension Registry 699 The EPP extension described in this document should be registered by 700 the IANA in the EPP Extension Registry described in [RFC7451]. The 701 details of the registration are as follows: 703 Name of Extension: "Login Security Extension for the Extensible 704 Provisioning Protocol (EPP)" 706 Document status: Standards Track 708 Reference: (insert reference to RFC version of this document) 710 Registrant Name and Email Address: IESG, 712 TLDs: Any 714 IPR Disclosure: None 716 Status: Active 718 Notes: None 720 7. Implementation Status 722 Note to RFC Editor: Please remove this section and the reference to 723 RFC 7942 [RFC7942] before publication. 725 This section records the status of known implementations of the 726 protocol defined by this specification at the time of posting of this 727 Internet-Draft, and is based on a proposal described in RFC 7942 728 [RFC7942]. The description of implementations in this section is 729 intended to assist the IETF in its decision processes in progressing 730 drafts to RFCs. Please note that the listing of any individual 731 implementation here does not imply endorsement by the IETF. 732 Furthermore, no effort has been spent to verify the information 733 presented here that was supplied by IETF contributors. This is not 734 intended as, and must not be construed to be, a catalog of available 735 implementations or their features. Readers are advised to note that 736 other implementations may exist. 738 According to RFC 7942 [RFC7942], "this will allow reviewers and 739 working groups to assign due consideration to documents that have the 740 benefit of running code, which may serve as evidence of valuable 741 experimentation and feedback that have made the implemented protocols 742 more mature. It is up to the individual working groups to use this 743 information as they see fit". 745 7.1. Verisign EPP SDK 747 Organization: Verisign Inc. 749 Name: Verisign EPP SDK 751 Description: The Verisign EPP SDK includes both a full client 752 implementation and a full server stub implementation of draft-ietf- 753 regext-login-security. 755 Level of maturity: Development 757 Coverage: All aspects of the protocol are implemented. 759 Licensing: GNU Lesser General Public License 761 Contact: jgould@verisign.com 763 URL: https://www.verisign.com/en_US/channel-resources/domain- 764 registry-products/epp-sdks 766 8. Security Considerations 768 The extension leaves the password ( element) and new password 769 ( element) minimum length beyond 6 characters and the maximum 770 length up to sever policy. The server SHOULD enforce minimum and 771 maximum length requirements that are appropriate for their operating 772 environment. One example of a guideline for password length policies 773 can be found in section 5 of NIST Special Publication 800-63B [1]. 775 The client SHOULD NOT decrease the security of a new password by 776 decreasing the length of the current password. For example, a client 777 with a 20 character password set using the extension, should not use 778 the login command in [RFC5730] without using the extension, to set a 779 new password that is less than or equal to 16 characters. 781 The extension provides an extensible list of login security events to 782 inform clients of connection and login warnings and errors. 784 9. Acknowledgements 786 The authors wish to thank the following persons for their feedback 787 and suggestions: 789 o Martin Casanova 790 o Scott Hollenbeck 791 o Patrick Mevzek 793 10. References 795 10.1. Normative References 797 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 798 Requirement Levels", BCP 14, RFC 2119, 799 DOI 10.17487/RFC2119, March 1997, . 802 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 803 DOI 10.17487/RFC3688, January 2004, . 806 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 807 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 808 . 810 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 811 Code: The Implementation Status Section", BCP 205, 812 RFC 7942, DOI 10.17487/RFC7942, July 2016, 813 . 815 [W3C.REC-xmlschema-2-20041028] 816 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 817 Second Edition", World Wide Web Consortium Recommendation 818 REC-xmlschema-2-20041028, October 2004, 819 . 821 10.2. Informative References 823 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 824 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 825 February 2015, . 827 10.3. URIs 829 [1] https://pages.nist.gov/800-63-3/sp800-63b.html 831 Appendix A. Change History 833 A.1. Change from 00 to 01 835 1. Based on the feedback from Patrick Mevzek and a proposal from 836 Scott Hollenbeck, changed the minimum length of the password from 837 8 to 6, revised the description of the password, and added text 838 in the Security Considerations section for the server password 839 length policy. 841 A.2. Change from 01 to 02 843 1. Changed the XML namespace from urn:ietf:params:xml:ns:loginSec- 844 0.3 to urn:ietf:params:xml:ns:epp:loginSec-0.3, and changed the 845 XML schema registration from urn:ietf:params:xml:ns:loginSec-0.3 846 to urn:ietf:params:xml:schema:epp:loginSec-0.3 based on a request 847 from IANA with draft-ietf-regext-allocation-token. 849 A.3. Change from 02 to 03 851 Updates based on the review by Patrick Mevzek, that include: 853 1. Fix the inconsistent case for newPW, that required a global 854 change in the draft text and an update to the XML schema to 855 "urn:ietf:params:xml:ns:loginSec-0.3". 856 2. Changed "contains the following child elements" to "MUST contain 857 at least one of the following child elements", section "EPP 858 Command" to ensure that an empty 859 element is not passed. 860 3. Add "The client SHOULD NOT decrease the security of a new 861 password by decreasing the length of the current password." along 862 with an example to the "Security Considerations" section. 864 A.4. Change from 03 to REGEXT 00 866 Changed to regext working group draft by changing draft-gould-regext- 867 login-security to draft-ietf-regext-login-security. 869 A.5. Change from REGEXT 00 to REGEXT 01 871 Changed the element to be structured with the 872 , , and sub-elements. 873 This was based on the feedback from Martin Casanova. This resulted 874 in the need to change the XML namespace from 875 urn:ietf:params:xml:ns:epp:loginSec-0.3 to 876 urn:ietf:params:xml:ns:epp:loginSec-0.4. 878 A.6. Change from REGEXT 01 to REGEXT 02 880 Updated the Implementation Status section from "TBD" to include the 881 Verisign EPP SDK implementation. 883 Authors' Addresses 885 James Gould 886 VeriSign, Inc. 887 12061 Bluemont Way 888 Reston, VA 20190 889 US 891 Email: jgould@verisign.com 892 URI: http://www.verisign.com 894 Matthew Pozun 895 VeriSign, Inc. 896 12061 Bluemont Way 897 Reston, VA 20190 898 US 900 Email: mpozun@verisign.com 901 URI: http://www.verisign.com