idnits 2.17.1 draft-ietf-regext-login-security-01.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 (April 9, 2019) is 1844 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 788 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: October 11, 2019 April 9, 2019 7 Login Security Extension for the Extensible Provisioning Protocol (EPP) 8 draft-ietf-regext-login-security-01 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 October 11, 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 8. Security Considerations . . . . . . . . . . . . . . . . . . . 17 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 18 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 18 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 18 74 10.2. Informative References . . . . . . . . . . . . . . . . . 18 75 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 19 76 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 19 77 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 19 78 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 19 79 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 19 80 A.4. Change from 03 to REGEXT 00 . . . . . . . . . . . . . . . 19 81 A.5. Change from REGEXT 00 to REGEXT 01 . . . . . . . . . . . 19 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 84 1. Introduction 86 This document describes an Extensible Provisioning Protocol (EPP) 87 extension for enhancing the security of the EPP login command in EPP 88 RFC 5730. The enhancements include supporting longer passwords (or 89 passphrases) than the 16-character maximum and providing a list of 90 security events in the login response. The password (current and 91 new) in EPP RFC 5730 can be overridden by the password included in 92 the extension to extend past the 16-character maximum. The security 93 events supported include: password expiry, client certificate expiry, 94 insecure cipher, insecure TLS protocol, new pasword complexity, login 95 security statistical warning, and a custom event. The attributes 96 supported by the security events include identifying the event type 97 or sub-type, indicating the security level of warning or error, a 98 future or past-due expiration date, the value that resulted in the 99 event, the duration of the statistical event, and a free-form 100 description with an optional language. 102 1.1. Conventions Used in This Document 104 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 105 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 106 document are to be interpreted as described in RFC 2119 [RFC2119]. 108 XML is case sensitive. Unless stated otherwise, XML specifications 109 and examples provided in this document MUST be interpreted in the 110 character case presented in order to develop a conforming 111 implementation. 113 In examples, "C:" represents lines sent by a protocol client and "S:" 114 represents lines returned by a protocol server. Indentation and 115 white space in examples are provided only to illustrate element 116 relationships and are not a REQUIRED feature of this protocol. 118 "loginSec-0.4" is used as an abbreviation for 119 "urn:ietf:params:xml:ns:epp:loginSec-0.4". The XML namespace prefix 120 "loginSec" is used, but implementations MUST NOT depend on it and 121 instead employ a proper namespace-aware XML parser and serializer to 122 interpret and output the XML documents. 124 2. Migrating to Newer Versions of This Extension 126 (Note to RFC Editor: remove this section before publication as an 127 RFC.) 129 Servers which implement this extension SHOULD provide a way for 130 clients to progressively update their implementations when a new 131 version of the extension is deployed. 133 Servers SHOULD (for a temporary migration period) provide support for 134 older versions of the extension in parallel to the newest version, 135 and allow clients to select their preferred version via the 136 element of the command. 138 If a client requests multiple versions of the extension at login, 139 then, when preparing responses to commands which do not include 140 extension elements, the server SHOULD only include extension elements 141 in the namespace of the newest version of the extension requested by 142 the client. 144 When preparing responses to commands which do include extension 145 elements, the server SHOULD only include extension elements for the 146 extension versions present in the command. 148 3. Object Attributes 150 This extension adds additional elements to [RFC5730] login command 151 and response. Only those new elements are described here. 153 3.1. Event 155 A security event, using the element, represents 156 either a warning or error identified by the server after the client 157 has connected and submitted the login command. There MAY be multiple 158 events returned that provides information for the client to address. 159 The MAY include a free form description. All of the 160 security events use a consistent set of attributes, where the exact 161 set of applicable attributes is based on the event type. The 162 supported set of element attributes include: 164 "type": A REQUIRED attribute that defines the type of security 165 event. The enumerated list of "type" values include: 167 "password": Identifies a password expiry event, where the 168 password expires in the future or has expired based on the 169 "exDate" date and time. 170 "certificate": Identifies a client certificate expiry event, 171 where the client certificate will expire at the "exDate" date 172 and time. 173 "cipher": Identifies the use of an insecure or deprecated TLS 174 cipher suite. 175 "tlsProtocol": Identifies the use of an insecure or deprecated 176 TLS protocol. 177 "newPW": The new password does not meet the server password 178 complexity requirements. 179 "stat": Provides a login security statistical warning that MUST 180 set the "name" of the statistic. 181 "custom": Custom event type that MUST set the "name" attribute 182 with the custom event type name. 183 "name": Used to define a sub-type or the type name when the "type" 184 attribute is "custom". 185 "level": Defines the level of the event as either "warning" for a 186 warning event that needs action, or "error" for an error event 187 that requires immediate action. 188 "exDate": Contains the date and time that a "warning" level has or 189 will become an "error" level. At expiry there MAY be an error to 190 connect or MAY be an error to login. An example is an expired 191 certificate that will result in a error to connect or an expired 192 password that may result in a failed login. 193 "value": Identifies the value that resulted in the login security 194 event. An example is the negotiated insecure cipher suite or the 195 negotiated insecure TLS protocol. 196 "duration": Defines the duration that a statistical event is 197 associated with. 198 "lang": Identifies the language of the free form description if the 199 negotiated language is something other than the default value of 200 "en" (English). 202 Example login security event for a password expiring in a week: 204 209 Password expiration soon 210 212 Example login security event for identifying 100 failed logins over 213 the last day, using the "stat" sub-type of "failedLogins": 215 221 Excessive invalid daily logins 222 224 3.2. "[LOGIN-SECURITY]" Password 226 The element MUST override the [RFC5730] element 227 only if the contains the predefined value of "[LOGIN-SECURITY]", 228 which is a constant value for the server to use the 229 element for the password. Similarly, the element 230 MUST override the [RFC5730] element only if the 231 contains the predefined value of "[LOGIN-SECURITY]", which is a 232 constant value for the server to use the element for 233 the new password. The "[LOGIN-SECURITY]" pre-defined string MUST be 234 supported by the server for the client to explicitly indicate to the 235 server whether to use element in place of the [RFC5730] 236 element or to use the in place of the [RFC5730] 237 element. 239 3.3. Dates and Times 241 Date and time attribute values MUST be represented in Universal 242 Coordinated Time (UTC) using the Gregorian calendar. The extended 243 date-time form using upper case "T" and "Z" characters defined in 244 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 245 values, as XML Schema does not support truncated date-time forms or 246 lower case "T" and "Z" characters. 248 4. EPP Command Mapping 250 A detailed description of the EPP syntax and semantics can be found 251 in the EPP core protocol specification [RFC5730]. 253 4.1. EPP Command 255 This extension defines additional elements to extend the EPP 256 command and response to be used in conjunction with [RFC5730]. 258 The EPP command is used to establish a session with an EPP 259 server. This extension overrides the password that is passed with 260 the [RFC5730] or the element as defined in Section 3.2. 261 A element is sent along with the [RFC5730] 262 command and MUST contain at least one of the following child 263 elements: 265 : OPTIONAL client user agent that identifies the 266 client software, language, and operating system used by the 267 server to identify functional or security constraints, current 268 security issues, and potential future functional or security 269 issues for the client. The element contains 270 the following child elements: 272 : OPTIONAL name of the client application software 273 with version if available, such as the name of the client SDK 274 "EPP SDK 1.0.0". 275 : OPTIONAL technology used for the client 276 software with version if available, such as "Java 11.0.2". 277 : OPTIONAL client operating system used with 278 version if available, such as "x86_64 Mac OS X 10.11.6". 279 : OPTIONAL plain text password that is case sensitive, 280 has a minimum length of 6 characters, and has a maximum length 281 that is up to server policy. All leading and trailing whitespace 282 is removed, and all internal contiguous whitespace that includes 283 #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20 284 (space) is replaced with a single #x20 (space). This element 285 MUST only be used if the [RFC5730] element is set to the 286 "[LOGIN-SECURITY]" value. 287 : OPTIONAL plain text new password that is case 288 sensitive, has a minimum length of 6 characters, and has a 289 maximum length that is up to server policy. All leading and 290 trailing whitespace is removed, and all internal contiguous 291 whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage 292 return), and #x20 (space) is replaced with a single #x20 (space). 293 This element MUST only be used if the [RFC5730] element 294 is set to the "[LOGIN-SECURITY]" value. 296 Example login command that uses the element instead of 297 the [RFC5730] element to establish the session and includes the 298 element: 300 C: 301 C: 302 C: 303 C: 304 C: ClientX 305 C: [LOGIN-SECURITY] 306 C: 307 C: 1.0 308 C: en 309 C: 310 C: 311 C: urn:ietf:params:xml:ns:obj1 312 C: urn:ietf:params:xml:ns:obj2 313 C: urn:ietf:params:xml:ns:obj3 314 C: 315 C: urn:ietf:params:xml:ns:epp:loginSec-0.4 316 C: 317 C: 318 C: 319 C: 320 C: 323 C: 324 C: EPP SDK 1.0.0 325 C: Java 11.0.2 326 C: x86_64 Mac OS X 10.11.6 327 C: 328 C: this is a long password 329 C: 330 C: 331 C: ABC-12345 332 C: 333 C: 334 Example login command that uses the element instead of 335 the [RFC5730] element to establish the session, and uses the 336 element instead of the [RFC5730] element to 337 set the new password: 339 C: 340 C: 341 C: 342 C: 343 C: ClientX 344 C: [LOGIN-SECURITY] 345 C: [LOGIN-SECURITY] 346 C: 347 C: 1.0 348 C: en 349 C: 350 C: 351 C: urn:ietf:params:xml:ns:obj1 352 C: urn:ietf:params:xml:ns:obj2 353 C: urn:ietf:params:xml:ns:obj3 354 C: 355 C: urn:ietf:params:xml:ns:epp:loginSec-0.4 356 C: 357 C: 358 C: 359 C: 360 C: 363 C: this is a long password 364 C: 365 C: new password that is still long 366 C: 367 C: 368 C: 369 C: ABC-12345 370 C: 371 C: 372 Example login command that uses the [RFC5730] element to 373 establish the session, and uses the element instead 374 of the [RFC5730] element to set the new password: 376 C: 377 C: 378 C: 379 C: 380 C: ClientX 381 C: shortpassword 382 C: [LOGIN-SECURITY] 383 C: 384 C: 1.0 385 C: en 386 C: 387 C: 388 C: urn:ietf:params:xml:ns:obj1 389 C: urn:ietf:params:xml:ns:obj2 390 C: urn:ietf:params:xml:ns:obj3 391 C: 392 C: urn:ietf:params:xml:ns:epp:loginSec-0.4 393 C: 394 C: 395 C: 396 C: 397 C: 400 C: new password that is still long 401 C: 402 C: 403 C: 404 C: ABC-12345 405 C: 406 C: 408 Upon a completed login command (success or failed), the extension 409 MUST be included in the response based on the following conditions: 411 Client supports extension: client supports the extension based on 412 the element of the command. 413 At least one login security event: The server has identified at 414 least one login security event to communicate to the client. 416 The extension to the EPP response uses the 417 element that contains the following child elements: 419 : One or more elements defined in 420 Section 3.1. 422 Example EPP response to a successful login command where the password 423 will expire in a week: 425 S: 426 S: 427 S: 428 S: 429 S: Command completed successfully 430 S: 431 S: 432 S: 435 S: 440 S: Password expiring in a week 441 S: 442 S: 443 S: 444 S: 445 S: ABC-12345 446 S: 54321-XYZ 447 S: 448 S: 449 S: 450 Example EPP response to a failed login command where the password has 451 expired and the new password does not meet the server complexity 452 requirements: 454 S: 455 S: 456 S: 457 S: 458 S: Authentication error 459 S: 460 S: 461 S: 464 S: 468 S: Password has expired 469 S: 470 S: 473 S: New password does not meet complexity requirements 474 S: 475 S: 476 S: 477 S: 478 S: ABC-12345 479 S: 54321-XYZ 480 S: 481 S: 482 S: 484 Example EPP response to a successful login command where there is a 485 set of login security events: 487 S: 488 S: 489 S: 490 S: 491 S: Command completed successfully 492 S: 493 S: 494 S: 497 S: 502 S: Password expiration soon 503 S: 504 S: 508 S: 512 S: Non-PFS Cipher negotiated 513 S: 514 S: 518 S: Insecure TLS protocol negotiated 519 S: 520 S: 526 S: Excessive invalid daily logins 527 S: 528 S: 532 S: A custom login security event occured 533 S: 534 S: 535 S: 536 S: 537 S: ABC-12345 538 S: 54321-XYZ 539 S: 540 S: 541 S: 543 5. Formal Syntax 545 One schema is presented here that is the EPP Login Security Extension 546 schema. 548 The formal syntax presented here is a complete schema representation 549 of the object mapping suitable for automated validation of EPP XML 550 instances. The BEGIN and END tags are not part of the schema; they 551 are used to note the beginning and ending of the schema for URI 552 registration purposes. 554 5.1. Login Security Extension Schema 556 BEGIN 557 558 565 568 569 571 572 Extensible Provisioning Protocol v1.0 573 Login Security Extension Schema. 574 576 577 579 582 583 584 586 588 590 592 594 595 596 597 598 600 601 602 604 606 608 609 611 612 614 615 616 619 620 622 623 624 625 626 628 630 632 634 636 638 641 642 643 645 648 649 650 651 652 653 654 655 656 657 658 660 663 664 665 666 667 668 669 672 673 END 675 6. IANA Considerations 677 6.1. XML Namespace 679 This document uses URNs to describe XML namespaces and XML schemas 680 conforming to a registry mechanism described in [RFC3688]. The 681 following URI assignment is requested of IANA: 683 Registration request for the loginSec namespace: 685 URI: urn:ietf:params:xml:ns:epp:loginSec-0.4 686 Registrant Contact: IESG 687 XML: None. Namespace URIs do not represent an XML specification. 689 Registration request for the loginSec XML schema: 691 URI: urn:ietf:params:xml:schema:epp:loginSec-0.4 692 Registrant Contact: IESG 693 XML: See the "Formal Syntax" section of this document. 695 6.2. EPP Extension Registry 697 The EPP extension described in this document should be registered by 698 the IANA in the EPP Extension Registry described in [RFC7451]. The 699 details of the registration are as follows: 701 Name of Extension: "Login Security Extension for the Extensible 702 Provisioning Protocol (EPP)" 704 Document status: Standards Track 706 Reference: (insert reference to RFC version of this document) 708 Registrant Name and Email Address: IESG, 710 TLDs: Any 712 IPR Disclosure: None 714 Status: Active 716 Notes: None 718 7. Implementation Status 720 Note to RFC Editor: Please remove this section and the reference to 721 RFC 7942 [RFC7942] before publication. 723 TBD 725 8. Security Considerations 727 The extension leaves the password ( element) and new password 728 ( element) minimum length beyond 6 characters and the maximum 729 length up to sever policy. The server SHOULD enforce minimum and 730 maximum length requirements that are appropriate for their operating 731 environment. One example of a guideline for password length policies 732 can be found in section 5 of NIST Special Publication 800-63B [1]. 734 The client SHOULD NOT decrease the security of a new password by 735 decreasing the length of the current password. For example, a client 736 with a 20 character password set using the extension, should not use 737 the login command in [RFC5730] without using the extension, to set a 738 new password that is less than or equal to 16 characters. 740 The extension provides an extensible list of login security events to 741 inform clients of connection and login warnings and errors. 743 9. Acknowledgements 745 The authors wish to thank the following persons for their feedback 746 and suggestions: 748 o Martin Casanova 749 o Scott Hollenbeck 750 o Patrick Mevzek 752 10. References 754 10.1. Normative References 756 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 757 Requirement Levels", BCP 14, RFC 2119, 758 DOI 10.17487/RFC2119, March 1997, . 761 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 762 DOI 10.17487/RFC3688, January 2004, . 765 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 766 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 767 . 769 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 770 Code: The Implementation Status Section", BCP 205, 771 RFC 7942, DOI 10.17487/RFC7942, July 2016, 772 . 774 [W3C.REC-xmlschema-2-20041028] 775 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 776 Second Edition", World Wide Web Consortium Recommendation 777 REC-xmlschema-2-20041028, October 2004, 778 . 780 10.2. Informative References 782 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 783 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 784 February 2015, . 786 10.3. URIs 788 [1] https://pages.nist.gov/800-63-3/sp800-63b.html 790 Appendix A. Change History 792 A.1. Change from 00 to 01 794 1. Based on the feedback from Patrick Mevzek and a proposal from 795 Scott Hollenbeck, changed the minimum length of the password from 796 8 to 6, revised the description of the password, and added text 797 in the Security Considerations section for the server password 798 length policy. 800 A.2. Change from 01 to 02 802 1. Changed the XML namespace from urn:ietf:params:xml:ns:loginSec- 803 0.3 to urn:ietf:params:xml:ns:epp:loginSec-0.3, and changed the 804 XML schema registration from urn:ietf:params:xml:ns:loginSec-0.3 805 to urn:ietf:params:xml:schema:epp:loginSec-0.3 based on a request 806 from IANA with draft-ietf-regext-allocation-token. 808 A.3. Change from 02 to 03 810 Updates based on the review by Patrick Mevzek, that include: 812 1. Fix the inconsistent case for newPW, that required a global 813 change in the draft text and an update to the XML schema to 814 "urn:ietf:params:xml:ns:loginSec-0.3". 815 2. Changed "contains the following child elements" to "MUST contain 816 at least one of the following child elements", section "EPP 817 Command" to ensure that an empty 818 element is not passed. 819 3. Add "The client SHOULD NOT decrease the security of a new 820 password by decreasing the length of the current password." along 821 with an example to the "Security Considerations" section. 823 A.4. Change from 03 to REGEXT 00 825 Changed to regext working group draft by changing draft-gould-regext- 826 login-security to draft-ietf-regext-login-security. 828 A.5. Change from REGEXT 00 to REGEXT 01 830 Changed the element to be structured with the 831 , , and sub-elements. 832 This was based on the feedback from Martin Casanova. This resulted 833 in the need to change the XML namespace from 834 urn:ietf:params:xml:ns:epp:loginSec-0.3 to 835 urn:ietf:params:xml:ns:epp:loginSec-0.4. 837 Authors' Addresses 839 James Gould 840 VeriSign, Inc. 841 12061 Bluemont Way 842 Reston, VA 20190 843 US 845 Email: jgould@verisign.com 846 URI: http://www.verisign.com 848 Matthew Pozun 849 VeriSign, Inc. 850 12061 Bluemont Way 851 Reston, VA 20190 852 US 854 Email: mpozun@verisign.com 855 URI: http://www.verisign.com