idnits 2.17.1 draft-ietf-regext-login-security-09.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 24, 2020) is 1524 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 932 == Missing Reference: 'LOGIN-SECURITY' is mentioned on line 266, but not defined -- Looks like a reference, but probably isn't: '2' on line 935 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 27, 2020 February 24, 2020 7 Login Security Extension for the Extensible Provisioning Protocol (EPP) 8 draft-ietf-regext-login-security-09 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 27, 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 . . . . . . . . . . . . . . . . . . . . . 6 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 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 27 93 1. Introduction 95 This document describes an Extensible Provisioning Protocol (EPP) 96 extension for enhancing the security of the EPP login command in EPP 97 [RFC5730]. The enhancements include supporting longer passwords (or 98 passphrases) than the 16-character maximum and providing a list of 99 security events in the login response. The password (current and 100 new) in EPP [RFC5730] can be overridden by the password included in 101 the extension to extend past the 16-character maximum. The security 102 events supported include: password expiry, client certificate expiry, 103 insecure cipher, insecure TLS protocol, new password complexity, 104 login security statistical warning, and a custom event. The 105 attributes supported by the security events include identifying the 106 event type or sub-type, indicating the security level of warning or 107 error, a future or past-due expiration date, the value that resulted 108 in the event, the duration of the statistical event, and a free-form 109 description with an optional language. 111 1.1. Conventions Used in This Document 113 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 114 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 115 "OPTIONAL" in this document are to be interpreted as described in BCP 116 14 [RFC2119] [RFC8174] when, and only when, they appear in all 117 capitals, as shown here. 119 XML is case sensitive. Unless stated otherwise, XML specifications 120 and examples provided in this document MUST be interpreted in the 121 character case presented in order to develop a conforming 122 implementation. 124 In examples, "C:" represents lines sent by a protocol client and "S:" 125 represents lines returned by a protocol server. Indentation and 126 white space in examples are provided only to illustrate element 127 relationships and are not a required feature of this protocol. 129 "loginSec-1.0" is used as an abbreviation for 130 "urn:ietf:params:xml:ns:epp:loginSec-1.0". The XML namespace prefix 131 "loginSec" is used, but implementations MUST NOT depend on it and 132 instead employ a proper namespace-aware XML parser and serializer to 133 interpret and output the XML documents. 135 "whitespace" is defined by the XML schema whiteSpace datatype in 136 [W3C.REC-xmlschema-2-20041028], which only includes the ASCII 137 whitespace characters #x9 (tab), #xA (linefeed), #xD (carriage 138 return), and #x20 (space). 140 2. Migrating to Newer Versions of This Extension 142 Servers which implement this extension SHOULD provide a way for 143 clients to progressively update their implementations when a new 144 version of the extension is deployed. A newer version of the 145 extension is expected to use an XML namespace with a higher version 146 number than the prior versions. 148 Servers SHOULD (for a temporary migration period up to server policy) 149 provide support for older versions of the extension in parallel to 150 the newest version, and allow clients to select their preferred 151 version via the element of the command. 153 If a client requests multiple versions of the extension at login, 154 then, when preparing responses to commands which do not include 155 extension elements, the server SHOULD only include extension elements 156 in the namespace of the newest version of the extension requested by 157 the client. 159 When preparing responses to commands which do include extension 160 elements, the server SHOULD only include extension elements for the 161 extension versions present in the command. 163 3. Object Attributes 165 This extension adds additional elements to [RFC5730] login command 166 and response. Only those new elements are described here. 168 3.1. Event 170 A security event, using the element, represents 171 either a warning or error identified by the server after the client 172 has connected and submitted the login command. The 173 element is contained in a list of one or more elements in the 174 element, so there MAY be multiple events 175 returned that provide information for the client to address. The 176 MAY include a free-form description. All of the 177 security events use a consistent set of attributes, where the exact 178 set of applicable attributes is based on the event type. The 179 supported set of element attributes include: 181 "type": A REQUIRED attribute that defines the type of security 182 event. The enumerated list of "type" values includes: 184 "password": Identifies a password expiry event, where the 185 password expires in the future or has expired based on the 186 "exDate" date and time. The "exDate" attribute MUST be set 187 with the password expiry date and time. 188 "certificate": Identifies a client certificate expiry event, 189 where the client certificate will expire at the "exDate" date 190 and time. The "exDate" attribute MUST be set with the 191 certificate expiry date and time. 192 "cipher": Identifies the use of an insecure or deprecated TLS 193 cipher suite. The "name" attribute MUST be set with the name 194 of the cipher suite, which is free-form and is not expected 195 to be parsed and automatically addressed by the client. An 196 example of cipher suite names can be found in the TLS Cipher 197 Suites of the Transport Layer Security (TLS) Parameters IANA 198 Registry [1]. 199 "tlsProtocol": Identifies the use of an insecure or deprecated 200 TLS protocol. The "name" attribute MUST be set with the name 201 of the TLS protocol, which is free-form and is not expected 202 to be parsed and automatically addressed by the client. 203 "newPW": The new password does not meet the server password 204 complexity requirements. 205 "stat": Provides a login security statistical warning that MUST 206 set the "name" attribute to the name of the statistic sub- 207 type. 208 "custom": Custom event type that MUST set the "name" attribute 209 with the custom event type name. 210 "name": Used to define a sub-type when the "type" attribute is not 211 "custom" or the full type name when the "type" attribute is 212 "custom". The "name" attribute MUST be set when the "type" 213 attribute is "stat" or "custom". The possible set of "name" 214 values, by event type, can be discovered / negotiated out of band 215 to EPP or using a separate EPP extension designed to provide 216 server policy information to the client. 217 "level": Defines the level of the event as either "warning" for a 218 warning event that needs action, or "error" for an error event 219 that requires immediate action. 220 "exDate": Contains the date and time that a "warning" level has or 221 will become an "error" level. At expiry there MAY be a 222 connection failure or MAY be a login failure. An example is an 223 expired certification that will result in a connection failure or 224 an expired password that may result in a login failure. 225 "value": Identifies the value that resulted in the login security 226 event. An example is the negotiated insecure cipher suite or the 227 negotiated insecure TLS protocol. 228 "duration": Defines the duration that a statistical event is 229 associated with, ending when the login command was received. The 230 format of the duration is defined by the duration primitive 231 datatype in section 3.2.6 of [W3C.REC-xmlschema-2-20041028]. 232 "lang": Identifies the negotiated language of the free-form 233 description. The format of the language is defined by the 234 language primitive datatype in section 3.3.3 of 235 [W3C.REC-xmlschema-2-20041028]. The default is "en" (English). 237 Example login security event for password expiration, where the 238 current date is 2020-03-25: 240 245 Password expiration soon 246 248 Example login security event for identifying 100 failed logins over 249 the last day, using the "stat" sub-type of "failedLogins": 251 257 Excessive invalid daily logins 258 260 3.2. "[LOGIN-SECURITY]" Password 262 When the [RFC5730] element contains the predefined value of 263 "[LOGIN-SECURITY]", the element overrides the 264 element, which is a constant value for the server to use the 265 element for the password. Similarly, when the 266 [RFC5730] element contains the predefined value of "[LOGIN- 267 SECURITY]", the element overrides the 268 element, which is a constant value for the server to use the 269 element for the new password. The "[LOGIN- 270 SECURITY]" pre-defined string MUST be supported by the server for the 271 client to explicitly indicate to the server whether to use 272 element in place of the [RFC5730] element or to 273 use the in place of the [RFC5730] element. 274 The server MUST NOT allow the client to set the password to the value 275 "[LOGIN-SECURITY]". 277 3.3. Dates and Times 279 Date and time attribute values MUST be represented in Universal 280 Coordinated Time (UTC) using the Gregorian calendar. The extended 281 date-time form using upper case "T" and "Z" characters defined in 283 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 284 values, as XML Schema does not support truncated date-time forms or 285 lower case "T" and "Z" characters. 287 4. EPP Command Mapping 289 A detailed description of the EPP syntax and semantics can be found 290 in the EPP core protocol specification [RFC5730]. 292 4.1. EPP Command 294 This extension defines additional elements to extend the EPP 295 command and response to be used in conjunction with [RFC5730]. 297 The EPP command is used to establish a session with an EPP 298 server. This extension overrides the password that is passed with 299 the [RFC5730] or the element as defined in Section 3.2. 300 A element is sent along with the [RFC5730] 301 command and MUST contain at least one of the following child 302 elements: 304 : OPTIONAL client user agent information that 305 identifies the client application software, technology, and 306 operating system used by the server to identify functional or 307 security constraints, current security issues, and potential 308 future functional or security issues for the client. The server 309 may use the information for real-time identification and client 310 notification of security issues, such as keying off of the client 311 application software for executing security rule checks. The 312 server may capture the information to identify future security 313 policy issues, such as deprecating or removing TLS cipher suites 314 or TLS protocols. The element MUST contain 315 at least one of the following child elements: 317 : OPTIONAL name of the client application software 318 with version if available, such as the name of the client SDK 319 "EPP SDK 1.0.0". The element value can be 320 created by appending the version number to the name of the 321 application software, such as the Augmented Backus-Naur Form 322 (ABNF) grammar [RFC5234] format: 324 app = name SP version 325 name = 1*VCHAR 326 version = 1*VCHAR 327 : OPTIONAL technology used for the client 328 software with version if available, such as "Vendor Java 329 11.0.6". The element value can be created by 330 including the technology vendor, technology name, and 331 technology version, such as the Augmented Backus-Naur Form 332 (ABNF) grammar [RFC5234] format: 334 tech = vendor SP name SP version 335 vendor = 1*VCHAR 336 name = 1*VCHAR 337 version = 1*VCHAR 338 : OPTIONAL client operating system used with 339 version if available, such as "x86_64 Mac OS X 10.15.2". The 340 element value can be created by including the 341 operating system architecture, operating system name, and 342 operating system version, such as the Augmented Backus-Naur 343 Form (ABNF) grammar [RFC5234] format: 345 os = arch SP name SP version 346 arch = 1*VCHAR 347 name = 1*VCHAR 348 version = 1*VCHAR 349 : OPTIONAL plain text password that is case sensitive, 350 has a minimum length of 6 characters, and has a maximum length 351 that is up to server policy. All leading and trailing whitespace 352 is removed, and all internal contiguous whitespace that includes 353 #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20 354 (space) is replaced with a single #x20 (space). This element 355 MUST only be set if the [RFC5730] element is set to the 356 "[LOGIN-SECURITY]" value. 357 : OPTIONAL plain text new password that is case 358 sensitive, has a minimum length of 6 characters, and has a 359 maximum length that is up to server policy. All leading and 360 trailing whitespace is removed, and all internal contiguous 361 whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage 362 return), and #x20 (space) is replaced with a single #x20 (space). 363 This element MUST only be set if the [RFC5730] element is 364 set to the "[LOGIN-SECURITY]" value. 366 It is RECOMMENDED that the plain text password in the 367 and elements use printable ASCII characters #x20 368 (space) - #x7E (~), with high entropy, such as 128 bits. If non- 369 ASCII characters are supported with the plain text password, then use 370 a standard for passwords with international characters; the 371 OpaqueString PRECIS profile in [RFC8265] is recommended in the 372 absence of other considerations. 374 Example login command that uses the element instead of 375 the [RFC5730] element to establish the session and includes the 376 element: 378 C: 379 C: 380 C: 381 C: 382 C: ClientX 383 C: [LOGIN-SECURITY] 384 C: 385 C: 1.0 386 C: en 387 C: 388 C: 389 C: urn:ietf:params:xml:ns:obj1 390 C: urn:ietf:params:xml:ns:obj2 391 C: urn:ietf:params:xml:ns:obj3 392 C: 393 C: urn:ietf:params:xml:ns:epp:loginSec-1.0 394 C: 395 C: 396 C: 397 C: 398 C: 401 C: 402 C: EPP SDK 1.0.0 403 C: Vendor Java 11.0.6 404 C: x86_64 Mac OS X 10.15.2 405 C: 406 C: this is a long password 407 C: 408 C: 409 C: ABC-12345 410 C: 411 C: 412 Example login command that uses the element instead of 413 the [RFC5730] element to establish the session, and uses the 414 element instead of the [RFC5730] element to 415 set the new password: 417 C: 418 C: 419 C: 420 C: 421 C: ClientX 422 C: [LOGIN-SECURITY] 423 C: [LOGIN-SECURITY] 424 C: 425 C: 1.0 426 C: en 427 C: 428 C: 429 C: urn:ietf:params:xml:ns:obj1 430 C: urn:ietf:params:xml:ns:obj2 431 C: urn:ietf:params:xml:ns:obj3 432 C: 433 C: urn:ietf:params:xml:ns:epp:loginSec-1.0 434 C: 435 C: 436 C: 437 C: 438 C: 441 C: this is a long password 442 C: 443 C: new password that is still long 444 C: 445 C: 446 C: 447 C: ABC-12345 448 C: 449 C: 450 Example login command that uses the [RFC5730] element to 451 establish the session, and uses the element instead 452 of the [RFC5730] element to set the new password: 454 C: 455 C: 456 C: 457 C: 458 C: ClientX 459 C: shortpassword 460 C: [LOGIN-SECURITY] 461 C: 462 C: 1.0 463 C: en 464 C: 465 C: 466 C: urn:ietf:params:xml:ns:obj1 467 C: urn:ietf:params:xml:ns:obj2 468 C: urn:ietf:params:xml:ns:obj3 469 C: 470 C: urn:ietf:params:xml:ns:epp:loginSec-1.0 471 C: 472 C: 473 C: 474 C: 475 C: 478 C: new password that is still long 479 C: 480 C: 481 C: 482 C: ABC-12345 483 C: 484 C: 486 Upon a completed login command (success or failed), the extension 487 MUST be included in the response when both of the following 488 conditions hold: 490 Client supports extension: The client supports the extension based 491 on the element of the command. 492 At least one login security event: The server has identified at 493 least one login security event to communicate to the client. 495 The extension to the EPP response uses the 496 element that contains the following child elements: 498 : One or more elements defined in 499 Section 3.1. 501 Example EPP response to a successful login command on 2020-03-25, 502 where the password will expire in a week: 504 S: 505 S: 506 S: 507 S: 508 S: Command completed successfully 509 S: 510 S: 511 S: 514 S: 519 S: Password expiring in a week 520 S: 521 S: 522 S: 523 S: 524 S: ABC-12345 525 S: 54321-XYZ 526 S: 527 S: 528 S: 529 Example EPP response to a failed login command where the password has 530 expired and the new password does not meet the server complexity 531 requirements: 533 S: 534 S: 535 S: 536 S: 537 S: Authentication error 538 S: 539 S: 540 S: 543 S: 547 S: Password has expired 548 S: 549 S: 552 S: New password does not meet complexity requirements 553 S: 554 S: 555 S: 556 S: 557 S: ABC-12345 558 S: 54321-XYZ 559 S: 560 S: 561 S: 563 Example EPP response to a successful login command where there is a 564 set of login security events: 566 S: 567 S: 568 S: 569 S: 570 S: Command completed successfully 571 S: 572 S: 573 S: 576 S: 581 S: Password expiration soon 582 S: 583 S: 587 S: 591 S: Non-PFS Cipher negotiated 592 S: 593 S: 597 S: Insecure TLS protocol negotiated 598 S: 599 S: 605 S: Excessive invalid daily logins 606 S: 607 S: 611 S: A custom login security event occured 612 S: 613 S: 614 S: 615 S: 616 S: ABC-12345 617 S: 54321-XYZ 618 S: 619 S: 620 S: 622 5. Formal Syntax 624 The EPP Login Security Extension schema is presented here. 626 The formal syntax presented here is a complete XML schema 627 representation of the object mapping suitable for automated 628 validation of EPP XML instances. The BEGIN and END tags are not part 629 of the XML schema; they are used to note the beginning and ending of 630 the XML schema for URI registration purposes. 632 5.1. Login Security Extension Schema 634 BEGIN 635 636 642 645 646 647 648 Extensible Provisioning Protocol v1.0 649 Login Security Extension Schema. 650 651 652 653 656 657 658 660 662 664 665 666 667 668 669 671 672 673 674 675 677 679 681 682 683 685 687 688 690 691 692 693 695 696 697 700 701 702 703 704 705 706 708 710 712 714 716 718 720 721 722 723 726 727 728 729 730 731 732 733 734 735 736 737 740 741 742 743 744 745 746 749 750 END 752 6. IANA Considerations 754 6.1. XML Namespace 756 This document uses URNs to describe XML namespaces and XML schemas 757 conforming to a registry mechanism described in [RFC3688]. The 758 following URI assignment is requested of IANA: 760 Registration request for the loginSec namespace: 762 URI: urn:ietf:params:xml:ns:epp:loginSec-1.0 763 Registrant Contact: IESG 764 XML: None. Namespace URIs do not represent an XML specification. 766 Registration request for the loginSec XML schema: 768 URI: urn:ietf:params:xml:schema:epp:loginSec-1.0 769 Registrant Contact: IESG 770 XML: See the "Formal Syntax" section of this document. 772 6.2. EPP Extension Registry 774 The EPP extension described in this document should be registered by 775 the IANA in the EPP Extension Registry described in [RFC7451]. The 776 details of the registration are as follows: 778 Name of Extension: "Login Security Extension for the Extensible 779 Provisioning Protocol (EPP)" 781 Document status: Standards Track 783 Reference: (insert reference to RFC version of this document) 785 Registrant Name and Email Address: IESG, 787 TLDs: Any 789 IPR Disclosure: None 791 Status: Active 793 Notes: None 795 7. Implementation Status 797 Note to RFC Editor: Please remove this section and the reference to 798 RFC 7942 [RFC7942] before publication. 800 This section records the status of known implementations of the 801 protocol defined by this specification at the time of posting of this 802 Internet-Draft, and is based on a proposal described in RFC 7942 803 [RFC7942]. The description of implementations in this section is 804 intended to assist the IETF in its decision processes in progressing 805 drafts to RFCs. Please note that the listing of any individual 806 implementation here does not imply endorsement by the IETF. 807 Furthermore, no effort has been spent to verify the information 808 presented here that was supplied by IETF contributors. This is not 809 intended as, and must not be construed to be, a catalog of available 810 implementations or their features. Readers are advised to note that 811 other implementations may exist. 813 According to RFC 7942 [RFC7942], "this will allow reviewers and 814 working groups to assign due consideration to documents that have the 815 benefit of running code, which may serve as evidence of valuable 816 experimentation and feedback that have made the implemented protocols 817 more mature. It is up to the individual working groups to use this 818 information as they see fit". 820 7.1. Verisign EPP SDK 822 Organization: Verisign Inc. 824 Name: Verisign EPP SDK 826 Description: The Verisign EPP SDK includes both a full client 827 implementation and a full server stub implementation of draft-ietf- 828 regext-login-security. 830 Level of maturity: Development 832 Coverage: All aspects of the protocol are implemented. 834 Licensing: GNU Lesser General Public License 836 Contact: jgould@verisign.com 838 URL: https://www.verisign.com/en_US/channel-resources/domain- 839 registry-products/epp-sdks 841 8. Security Considerations 843 The Security Considerations of [RFC5730] apply in this document, and 844 this document enhances these considerations. 846 The extension leaves the password ( element) and new password 847 ( element) minimum length greater than 6 characters and the 848 maximum length up to server policy. The server SHOULD enforce 849 minimum and maximum length requirements that are appropriate for 850 their operating environment. One example of a guideline for password 851 length policies can be found in section 5 of NIST Special Publication 852 800-63B [2]. 854 The client SHOULD NOT decrease the security of a new password by 855 decreasing the length of the current password. For example, a client 856 with a 20 character password set using the extension, should not use 857 the login command in [RFC5730] without using the extension, to set a 858 new password that is less than or equal to 16 characters. 860 The extension provides an extensible list of login security events to 861 inform clients of connection and login warnings and errors. The 862 server returning of security events to unauthenticated users needs to 863 take into account the security/privacy issues of returning 864 information to potential attackers. 866 The user agent information represents the client system of a system- 867 to-system interface, so the user agent information MUST NOT provide 868 any ability to track individual users or classes of users. 870 9. Acknowledgements 872 The authors wish to thank the following persons for their feedback 873 and suggestions: 875 o Martin Casanova 876 o Scott Hollenbeck 877 o Barry Leiba 878 o Patrick Mevzek 879 o Joseph Yee 881 10. References 883 10.1. Normative References 885 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 886 Requirement Levels", BCP 14, RFC 2119, 887 DOI 10.17487/RFC2119, March 1997, 888 . 890 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 891 DOI 10.17487/RFC3688, January 2004, 892 . 894 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 895 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 896 . 898 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 899 Code: The Implementation Status Section", BCP 205, 900 RFC 7942, DOI 10.17487/RFC7942, July 2016, 901 . 903 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 904 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 905 May 2017, . 907 [W3C.REC-xmlschema-2-20041028] 908 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 909 Second Edition", World Wide Web Consortium Recommendation 910 REC-xmlschema-2-20041028, October 2004, 911 . 913 10.2. Informative References 915 [RFC5234] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax 916 Specifications: ABNF", STD 68, RFC 5234, 917 DOI 10.17487/RFC5234, January 2008, 918 . 920 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 921 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 922 February 2015, . 924 [RFC8265] Saint-Andre, P. and A. Melnikov, "Preparation, 925 Enforcement, and Comparison of Internationalized Strings 926 Representing Usernames and Passwords", RFC 8265, 927 DOI 10.17487/RFC8265, October 2017, 928 . 930 10.3. URIs 932 [1] https://www.iana.org/assignments/tls-parameters/tls- 933 parameters.xhtml#tls-parameters-4 935 [2] https://pages.nist.gov/800-63-3/sp800-63b.html 937 Appendix A. Change History 939 [[RFC Editor: Please remove this section.]] 941 A.1. Change from 00 to 01 943 1. Based on the feedback from Patrick Mevzek and a proposal from 944 Scott Hollenbeck, changed the minimum length of the password from 945 8 to 6, revised the description of the password, and added text 946 in the Security Considerations section for the server password 947 length policy. 949 A.2. Change from 01 to 02 951 1. Changed the XML namespace from urn:ietf:params:xml:ns:loginSec- 952 0.3 to urn:ietf:params:xml:ns:epp:loginSec-0.3, and changed the 953 XML schema registration from urn:ietf:params:xml:ns:loginSec-0.3 954 to urn:ietf:params:xml:schema:epp:loginSec-0.3 based on a request 955 from IANA with draft-ietf-regext-allocation-token. 957 A.3. Change from 02 to 03 959 1. Updates based on the review by Patrick Mevzek, that include: 961 1. Fix the inconsistent case for newPW, that required a global 962 change in the draft text and an update to the XML schema to 963 "urn:ietf:params:xml:ns:loginSec-0.3". 964 2. Changed "contains the following child elements" to "MUST 965 contain at least one of the following child elements", 966 section "EPP Command" to ensure that an empty 967 element is not passed. 968 3. Add "The client SHOULD NOT decrease the security of a new 969 password by decreasing the length of the current password." 970 along with an example to the "Security Considerations" 971 section. 973 A.4. Change from 03 to REGEXT 00 975 1. Changed to regext working group draft by changing draft-gould- 976 regext-login-security to draft-ietf-regext-login-security. 978 A.5. Change from REGEXT 00 to REGEXT 01 980 1. Changed the element to be structured with 981 the , , and sub- 982 elements. This was based on the feedback from Martin Casanova. 983 This resulted in the need to change the XML namespace from 984 urn:ietf:params:xml:ns:epp:loginSec-0.3 to 985 urn:ietf:params:xml:ns:epp:loginSec-0.4. 987 A.6. Change from REGEXT 01 to REGEXT 02 989 1. Updated the Implementation Status section from "TBD" to include 990 the Verisign EPP SDK implementation. 992 A.7. Change from REGEXT 02 to REGEXT 03 994 1. Revised the description of the "duration" attribute to clarify 995 that it ends when the login command was received and to clarify 996 the format, based on the feedback from Martin Casanova. 997 2. Revised the sentence 'Upon a completed login command (success or 998 failed), the extension MUST be included in the response based on 999 the following conditions:' to 'Upon a completed login command 1000 (success or failed), the extension MUST be included in the 1001 response based on both of the following conditions:' based on the 1002 feedback from Patrick Mevzek. 1003 3. Updates based on the review by Joseph Yee, that include: 1005 1. Revised the description of the "name" 1006 attribute read 'Used to define a sub-type when the "type" 1007 attribute is not "custom" or the full type name when the 1008 "type" attribute is "custom"'. The definition of the "stat" 1009 type was updated to 'Provides a login security statistical 1010 warning that MUST set the "name" attribute to the name of the 1011 statistic.' 1012 2. Added the following sentence 'The server MUST NOT allow the 1013 client to set the password to the value "[LOGIN-SECURITY]".' 1014 to address the corner case where the constant is used as the 1015 password. 1016 3. Revised the description of the element 1017 to read 'The element MUST contain at 1018 least one of the following child elements:'. 1019 4. Revised the description of the to match the 1020 child elements that can be passed, by changing "client software" 1021 to "client application software" and change "language" to 1022 "technology". 1023 5. Changed the XML namespace from 1024 urn:ietf:params:xml:ns:epp:loginSec-0.4 to 1025 urn:ietf:params:xml:ns:epp:loginSec-1.0. 1027 A.8. Change from REGEXT 03 to REGEXT 04 1029 Updates based on the review by Joseph Yee, that include: 1031 1. Update the definition of the "stat" security event type to 1032 reference sub-type to match the language for the "name" 1033 attribute. 1034 2. Added the sentence 'The "name" attribute MUST be set when the 1035 "type" attribute is "stat" or "custom".' to the definition of the 1036 "name" attribute for clarity. 1037 3. Update the definition of the "userAgentType" in the XML schema to 1038 require at least one sub-element using a element. 1040 A.9. Change from REGEXT 04 to REGEXT 05 1042 Updates based on the review by Barry Leiba, that include: 1044 1. In section 1.1, updated to use BCP 14 boilerplate and references 1045 as defined in RFC 8174. 1046 2. In section 1.1, change "REQUIRED" to "required". 1047 3. Keep the "Migration to Newer Versions of This Extension" section 1048 by removing the note for removal to the RFC Editor. 1050 4. In section 3.1, change "MAY be multiple events returned that 1051 provides information" to "MAY be multiple events returned that 1052 provide information". 1053 5. In section 3.1, change "free form" to "free-form". 1054 6. In section 3.1, change "The enumerated list of "type" values 1055 include:" to "The enumerated list of "type" values includes:". 1056 7. In section 3.1, change "Identifies the language of the free-form 1057 description if the negotiated language is something other than 1058 the default value of "en" (English)." to "Identifies the 1059 negotiated language of the free-form description. The default is 1060 "en" (English). 1061 8. In section 3.1, change example description from "Example login 1062 security event for a password expiring in a week:" to "Example 1063 login security event for password expiration, where the current 1064 date is 2018-03-25:". 1065 9. In section 4.1, change "Example EPP response to a successful 1066 login command where the password will expire in a week:" to 1067 "Example EPP response to a successful login command on 1068 2018-03-25, where the password will expire in a week:". 1070 A.10. Change from REGEXT 05 to REGEXT 06 1072 Updates based on the review by Brian Carpenter, that include: 1074 1. In section 1, change the references to RFC 5730 to use links. 1075 2. In section 2, change "(for a temporary migration period)" to 1076 "(for a temporary migration period up to server policy)". 1078 A.11. Change from REGEXT 06 to REGEXT 07 1080 1. Updates based on feedback from Barry Leiba, added recommendations 1081 on the characters used for the plain text password. Recommended 1082 the use of printable ASCII passwords and if non-ASCII characters 1083 are supported, to use a standard for passwords with international 1084 characters, such as the OpaqueString PRECIS profile in [RFC8265]. 1085 2. Based on the feedback from Carlos Pignataro, added "[[RFC Editor: 1086 Please remove this section.]]" to the "Change History" section. 1088 A.12. Change from REGEXT 07 to REGEXT 08 1090 1. Based on feedback from Eric Vyncke during the IESG review, 1091 changed [RFC8174] from the informative references into the 1092 normative references. 1093 2. Based on feedback from Alissa Cooper during the IESG review, 1094 changed the sentence "One schema is presented here that is the 1095 EPP Login Security Extension schema." in section 5 to "The EPP 1096 Login Security Extension schema is presented here.". 1097 3. Changed "sever policy" to "server policy" in section 8. 1099 4. Updates based on feedback from Roman Danyliw during the IESG 1100 review: 1102 1. Changed "pasword" to "password" in section 1. 1103 2. In section 3.1, added a reference to section 3.3.3 of 1104 [W3C.REC-xmlschema-2-20041028] for the format of the "lang" 1105 attribute. Added the corresponding section (3.2.6) for the 1106 "duration" attribute. 1107 3. Added the "XML" prefix for each reference to "schema" in the 1108 introduction of section 5. 1109 4. Added the leading sentence "The Security Considerations of 1110 [RFC5730] apply in this document, and this document enhances 1111 these considerations." to section 8. 1112 5. Added the sentence 'The possible set of "name" values, by 1113 event type, can be discovered / negotiated out of band to EPP 1114 or using a separate EPP extension designed to provide server 1115 policy information to the client.' to the description of the 1116 "name" attribute. 1117 6. Added a description of how to create the , 1118 , and values using ABNF. 1119 5. Updates based on feedback from Alexey Melnikov during the IESG 1120 review: 1122 1. Added a description of "whitespace" to section 1.1. 1123 2. Added a description of the usage of the user agent 1124 information in section 4.1. 1125 6. Updates based on feedback from Benjamin Kaduk during the IESG 1126 review: 1128 1. Added "A newer version of the extension is expected to use 1129 an XML namespace with a higher version number than the prior 1130 versions." to the first paragraph of section 2. 1131 2. In section 3.1, replace the sentence "There MAY be multiple 1132 events returned that provide information for the client to 1133 address." with "The element is contained in 1134 a list of one or more elements in the 1135 element, so there MAY be multiple 1136 events returned that provide information for the client to 1137 address." 1138 3. In section 3.1, for the "exDate" attribute, replace the 1139 sentence "At expiry there MAY be an error to connect or MAY 1140 be an error to login." with "At expiry there MAY be a 1141 connection failure or MAY be a login failure." and a similar 1142 change to the following sentence. 1143 4. In section 3.1, replace the description of the "cipher" type 1144 and the "tlsProtocol" type. 1146 5. In section 3.1, add a sentence that the "exDate" attribute 1147 MUST be set for the "password" type and the "certificate" 1148 type. 1149 6. Updates the dates by replacing 2018 with 2020. 1150 7. In section 3.2, update the MUST override sentences for the 1151 and the elements. 1152 8. In section 4.1, update "OPTIONAL client user agent" with 1153 "OPTIONAL client user agent information" for the description 1154 of the element. 1155 9. In section 4.1, replace "MUST only be used" to "MUST only be 1156 set" for the and elements. 1157 10. Updated references of "x86_64 Mac OS X 10.11.6" to "x86_64 1158 Mac OS X 10.15.2". 1159 11. In section 4.1, replace "MUST be included in the response 1160 based on both of the following conditions" with "MUST be 1161 included in the response when both of the following 1162 conditions hold". 1163 12. In section 4.1, update the "exDate" for the "password" 1164 security event error to be "2020-03-24T22:00:00.0Z" so that 1165 it's prior to the date 2020-03-25 reference previously. 1166 13. In section 8, add the sentence "The server returning of 1167 security events to unauthenticated users needs to take into 1168 account the security/privacy issues of returning information 1169 to potential attackers." to the end of the last paragraph. 1170 14. In section 8, change "minimum length beyond 6 characters" to 1171 "minimum length greater than 6 characters". 1172 15. In section 8, add the sentence "The user agent information 1173 represents the client system of a system-to-system 1174 interface, so the user agent information MUST NOT provide 1175 any ability to track individual users or classes of users." 1177 A.13. Change from REGEXT 08 to REGEXT 09 1179 1. Based on feedback from Barry Leiba in responding to Benjamin 1180 Kaduk's discuss item, changed "It is recommended that the plain 1181 text..." to "It is RECOMMENDED that the plain text..." and "If 1182 non-ASCII characters are supported with the plain text password, 1183 then use a standard for passwords with international characters, 1184 such as the OpaqueString PRECIS profile in [RFC8265]." to "If 1185 non-ASCII characters are supported with the plain text password, 1186 then use a standard for passwords with international characters; 1187 the OpaqueString PRECIS profile in [RFC8265] is recommended in 1188 the absence of other considerations." 1190 Authors' Addresses 1192 James Gould 1193 VeriSign, Inc. 1194 12061 Bluemont Way 1195 Reston, VA 20190 1196 US 1198 Email: jgould@verisign.com 1199 URI: http://www.verisign.com 1201 Matthew Pozun 1202 VeriSign, Inc. 1203 12061 Bluemont Way 1204 Reston, VA 20190 1205 US 1207 Email: mpozun@verisign.com 1208 URI: http://www.verisign.com