idnits 2.17.1 draft-gould-regext-login-security-03.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 (January 15, 2019) is 1925 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 763 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: July 19, 2019 January 15, 2019 7 Login Security Extension for the Extensible Provisioning Protocol (EPP) 8 draft-gould-regext-login-security-03 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 July 19, 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 . . . . . . . . . . . . . . . . . . . . . . . . 13 65 5.1. Login Security Extension Schema . . . . . . . . . . . . . 13 66 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 67 6.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 15 68 6.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 16 69 7. Implementation Status . . . . . . . . . . . . . . . . . . . . 16 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 71 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 17 72 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 17 73 10.1. Normative References . . . . . . . . . . . . . . . . . . 17 74 10.2. Informative References . . . . . . . . . . . . . . . . . 17 75 10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 76 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 18 77 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 18 78 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 18 79 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 18 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 82 1. Introduction 84 This document describes an Extensible Provisioning Protocol (EPP) 85 extension for enhancing the security of the EPP login command in EPP 86 RFC 5730. The enhancements include supporting longer passwords (or 87 passphrases) than the 16-character maximum and providing a list of 88 security events in the login response. The password (current and 89 new) in EPP RFC 5730 can be overridden by the password included in 90 the extension to extend past the 16-character maximum. The security 91 events supported include: password expiry, client certificate expiry, 92 insecure cipher, insecure TLS protocol, new pasword complexity, login 93 security statistical warning, and a custom event. The attributes 94 supported by the security events include identifying the event type 95 or sub-type, indicating the security level of warning or error, a 96 future or past-due expiration date, the value that resulted in the 97 event, the duration of the statistical event, and a free-form 98 description with an optional language. 100 1.1. Conventions Used in This Document 102 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 103 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 104 document are to be interpreted as described in RFC 2119 [RFC2119]. 106 XML is case sensitive. Unless stated otherwise, XML specifications 107 and examples provided in this document MUST be interpreted in the 108 character case presented in order to develop a conforming 109 implementation. 111 In examples, "C:" represents lines sent by a protocol client and "S:" 112 represents lines returned by a protocol server. Indentation and 113 white space in examples are provided only to illustrate element 114 relationships and are not a REQUIRED feature of this protocol. 116 "loginSec-0.3" is used as an abbreviation for 117 "urn:ietf:params:xml:ns:epp:loginSec-0.3". The XML namespace prefix 118 "loginSec" is used, but implementations MUST NOT depend on it and 119 instead employ a proper namespace-aware XML parser and serializer to 120 interpret and output the XML documents. 122 2. Migrating to Newer Versions of This Extension 124 (Note to RFC Editor: remove this section before publication as an 125 RFC.) 127 Servers which implement this extension SHOULD provide a way for 128 clients to progressively update their implementations when a new 129 version of the extension is deployed. 131 Servers SHOULD (for a temporary migration period) provide support for 132 older versions of the extension in parallel to the newest version, 133 and allow clients to select their preferred version via the 134 element of the command. 136 If a client requests multiple versions of the extension at login, 137 then, when preparing responses to commands which do not include 138 extension elements, the server SHOULD only include extension elements 139 in the namespace of the newest version of the extension requested by 140 the client. 142 When preparing responses to commands which do include extension 143 elements, the server SHOULD only include extension elements for the 144 extension versions present in the command. 146 3. Object Attributes 148 This extension adds additional elements to [RFC5730] login command 149 and response. Only those new elements are described here. 151 3.1. Event 153 A security event, using the element, represents 154 either a warning or error identified by the server after the client 155 has connected and submitted the login command. There MAY be multiple 156 events returned that provides information for the client to address. 157 The MAY include a free form description. All of the 158 security events use a consistent set of attributes, where the exact 159 set of applicable attributes is based on the event type. The 160 supported set of element attributes include: 162 "type": A REQUIRED attribute that defines the type of security 163 event. The enumerated list of "type" values include: 165 "password": Identifies a password expiry event, where the 166 password expires in the future or has expired based on the 167 "exDate" date and time. 168 "certificate": Identifies a client certificate expiry event, 169 where the client certificate will expire at the "exDate" date 170 and time. 171 "cipher": Identifies the use of an insecure or deprecated TLS 172 cipher suite. 173 "tlsProtocol": Identifies the use of an insecure or deprecated 174 TLS protocol. 175 "newPW": The new password does not meet the server password 176 complexity requirements. 177 "stat": Provides a login security statistical warning that MUST 178 set the "name" of the statistic. 179 "custom": Custom event type that MUST set the "name" attribute 180 with the custom event type name. 181 "name": Used to define a sub-type or the type name when the "type" 182 attribute is "custom". 183 "level": Defines the level of the event as either "warning" for a 184 warning event that needs action, or "error" for an error event 185 that requires immediate action. 186 "exDate": Contains the date and time that a "warning" level has or 187 will become an "error" level. At expiry there MAY be an error to 188 connect or MAY be an error to login. An example is an expired 189 certificate that will result in a error to connect or an expired 190 password that may result in a failed login. 192 "value": Identifies the value that resulted in the login security 193 event. An example is the negotiated insecure cipher suite or the 194 negotiated insecure TLS protocol. 195 "duration": Defines the duration that a statistical event is 196 associated with. 197 "lang": Identifies the language of the free form description if the 198 negotiated language is something other than the default value of 199 "en" (English). 201 Example login security event for a password expiring in a week: 203 208 Password expiration soon 209 211 Example login security event for identifying 100 failed logins over 212 the last day, using the "stat" sub-type of "failedLogins": 214 220 Excessive invalid daily logins 221 223 3.2. "[LOGIN-SECURITY]" Password 225 The element MUST override the [RFC5730] element 226 only if the contains the predefined value of "[LOGIN-SECURITY]", 227 which is a constant value for the server to use the 228 element for the password. Similarly, the element 229 MUST override the [RFC5730] element only if the 230 contains the predefined value of "[LOGIN-SECURITY]", which is a 231 constant value for the server to use the element for 232 the new password. The "[LOGIN-SECURITY]" pre-defined string MUST be 233 supported by the server for the client to explicitly indicate to the 234 server whether to use element in place of the [RFC5730] 235 element or to use the in place of the [RFC5730] 236 element. 238 3.3. Dates and Times 240 Date and time attribute values MUST be represented in Universal 241 Coordinated Time (UTC) using the Gregorian calendar. The extended 242 date-time form using upper case "T" and "Z" characters defined in 243 [W3C.REC-xmlschema-2-20041028] MUST be used to represent date-time 244 values, as XML Schema does not support truncated date-time forms or 245 lower case "T" and "Z" characters. 247 4. EPP Command Mapping 249 A detailed description of the EPP syntax and semantics can be found 250 in the EPP core protocol specification [RFC5730]. 252 4.1. EPP Command 254 This extension defines additional elements to extend the EPP 255 command and response to be used in conjunction with [RFC5730]. 257 The EPP command is used to establish a session with an EPP 258 server. This extension overrides the password that is passed with 259 the [RFC5730] or the element as defined in Section 3.2. 260 A element is sent along with the [RFC5730] 261 command and MUST contain at least one of the following child 262 elements: 264 : OPTIONAL client user agent that identifies the 265 client software and platform used by the server to identify 266 functional or security constraints, current security issues, and 267 potential future functional or security issues for the client. 268 : OPTIONAL plain text password that is case sensitive, 269 has a minimum length of 6 characters, and has a maximum length 270 that is up to server policy. All leading and trailing whitespace 271 is removed, and all internal contiguous whitespace that includes 272 #x9 (tab), #xA (linefeed), #xD (carriage return), and #x20 273 (space) is replaced with a single #x20 (space). This element 274 MUST only be used if the [RFC5730] element is set to the 275 "[LOGIN-SECURITY]" value. 276 : OPTIONAL plain text new password that is case 277 sensitive, has a minimum length of 6 characters, and has a 278 maximum length that is up to server policy. All leading and 279 trailing whitespace is removed, and all internal contiguous 280 whitespace that includes #x9 (tab), #xA (linefeed), #xD (carriage 281 return), and #x20 (space) is replaced with a single #x20 (space). 282 This element MUST only be used if the [RFC5730] element 283 is set to the "[LOGIN-SECURITY]" value. 285 Example login command that uses the element instead of 286 the [RFC5730] element to establish the session and includes the 287 element: 289 C: 290 C: 291 C: 292 C: 293 C: ClientX 294 C: [LOGIN-SECURITY] 295 C: 296 C: 1.0 297 C: en 298 C: 299 C: 300 C: urn:ietf:params:xml:ns:obj1 301 C: urn:ietf:params:xml:ns:obj2 302 C: urn:ietf:params:xml:ns:obj3 303 C: 304 C: urn:ietf:params:xml:ns:epp:loginSec-0.3 305 C: 306 C: 307 C: 308 C: 309 C: 312 C: EPP SDK/1.0.0 313 C: (Java 1.7.0_15; x86_64 Mac OS X 10.11.6) 314 C: 315 C: this is a long password 316 C: 317 C: 318 C: ABC-12345 319 C: 320 C: 321 Example login command that uses the element instead of 322 the [RFC5730] element to establish the session, and uses the 323 element instead of the [RFC5730] element to 324 set the new password: 326 C: 327 C: 328 C: 329 C: 330 C: ClientX 331 C: [LOGIN-SECURITY] 332 C: [LOGIN-SECURITY] 333 C: 334 C: 1.0 335 C: en 336 C: 337 C: 338 C: urn:ietf:params:xml:ns:obj1 339 C: urn:ietf:params:xml:ns:obj2 340 C: urn:ietf:params:xml:ns:obj3 341 C: 342 C: urn:ietf:params:xml:ns:epp:loginSec-0.3 343 C: 344 C: 345 C: 346 C: 347 C: 350 C: this is a long password 351 C: 352 C: new password that is still long 353 C: 354 C: 355 C: 356 C: ABC-12345 357 C: 358 C: 359 Example login command that uses the [RFC5730] element to 360 establish the session, and uses the element instead 361 of the [RFC5730] element to set the new password: 363 C: 364 C: 365 C: 366 C: 367 C: ClientX 368 C: shortpassword 369 C: [LOGIN-SECURITY] 370 C: 371 C: 1.0 372 C: en 373 C: 374 C: 375 C: urn:ietf:params:xml:ns:obj1 376 C: urn:ietf:params:xml:ns:obj2 377 C: urn:ietf:params:xml:ns:obj3 378 C: 379 C: urn:ietf:params:xml:ns:epp:loginSec-0.3 380 C: 381 C: 382 C: 383 C: 384 C: 387 C: new password that is still long 388 C: 389 C: 390 C: 391 C: ABC-12345 392 C: 393 C: 395 Upon a completed login command (success or failed), the extension 396 MUST be included in the response based on the following conditions: 398 Client supports extension: client supports the extension based on 399 the element of the command. 400 At least one login security event: The server has identified at 401 least one login security event to communicate to the client. 403 The extension to the EPP response uses the 404 element that contains the following child elements: 406 : One or more elements defined in 407 Section 3.1. 409 Example EPP response to a successful login command where the password 410 will expire in a week: 412 S: 413 S: 414 S: 415 S: 416 S: Command completed successfully 417 S: 418 S: 419 S: 422 S: 427 S: Password expiring in a week 428 S: 429 S: 430 S: 431 S: 432 S: ABC-12345 433 S: 54321-XYZ 434 S: 435 S: 436 S: 437 Example EPP response to a failed login command where the password has 438 expired and the new password does not meet the server complexity 439 requirements: 441 S: 442 S: 443 S: 444 S: 445 S: Authentication error 446 S: 447 S: 448 S: 451 S: 455 S: Password has expired 456 S: 457 S: 460 S: New password does not meet complexity requirements 461 S: 462 S: 463 S: 464 S: 465 S: ABC-12345 466 S: 54321-XYZ 467 S: 468 S: 469 S: 471 Example EPP response to a successful login command where there is a 472 set of login security events: 474 S: 475 S: 476 S: 477 S: 478 S: Command completed successfully 479 S: 480 S: 481 S: 484 S: 489 S: Password expiration soon 490 S: 491 S: 495 S: 499 S: Non-PFS Cipher negotiated 500 S: 501 S: 505 S: Insecure TLS protocol negotiated 506 S: 507 S: 513 S: Excessive invalid daily logins 514 S: 515 S: 519 S: A custom login security event occured 520 S: 521 S: 522 S: 523 S: 524 S: ABC-12345 525 S: 54321-XYZ 526 S: 527 S: 528 S: 530 5. Formal Syntax 532 One schema is presented here that is the EPP Login Security Extension 533 schema. 535 The formal syntax presented here is a complete schema representation 536 of the object mapping suitable for automated validation of EPP XML 537 instances. The BEGIN and END tags are not part of the schema; they 538 are used to note the beginning and ending of the schema for URI 539 registration purposes. 541 5.1. Login Security Extension Schema 543 BEGIN 544 545 552 555 556 558 559 560 Extensible Provisioning Protocol v1.0 561 Login Security Extension Schema. 562 563 565 566 568 571 572 573 575 578 580 581 583 584 585 586 587 589 590 592 595 596 597 599 600 602 603 604 605 607 608 610 611 612 614 616 617 618 620 623 624 625 626 627 628 629 630 631 632 633 635 638 639 640 641 642 643 645 648 649 END 651 6. IANA Considerations 653 6.1. XML Namespace 655 This document uses URNs to describe XML namespaces and XML schemas 656 conforming to a registry mechanism described in [RFC3688]. The 657 following URI assignment is requested of IANA: 659 Registration request for the loginSec namespace: 661 URI: urn:ietf:params:xml:ns:epp:loginSec-0.3 662 Registrant Contact: IESG 663 XML: None. Namespace URIs do not represent an XML specification. 665 Registration request for the loginSec XML schema: 667 URI: urn:ietf:params:xml:schema:epp:loginSec-0.3 668 Registrant Contact: IESG 669 XML: See the "Formal Syntax" section of this document. 671 6.2. EPP Extension Registry 673 The EPP extension described in this document should be registered by 674 the IANA in the EPP Extension Registry described in [RFC7451]. The 675 details of the registration are as follows: 677 Name of Extension: "Login Security Extension for the Extensible 678 Provisioning Protocol (EPP)" 680 Document status: Standards Track 682 Reference: (insert reference to RFC version of this document) 684 Registrant Name and Email Address: IESG, 686 TLDs: Any 688 IPR Disclosure: None 690 Status: Active 692 Notes: None 694 7. Implementation Status 696 Note to RFC Editor: Please remove this section and the reference to 697 RFC 7942 [RFC7942] before publication. 699 TBD 701 8. Security Considerations 703 The extension leaves the password ( element) and new password 704 ( element) minimum length beyond 6 characters and the maximum 705 length up to sever policy. The server SHOULD enforce minimum and 706 maximum length requirements that are appropriate for their operating 707 environment. One example of a guideline for password length policies 708 can be found in section 5 of NIST Special Publication 800-63B [1]. 710 The client SHOULD NOT decrease the security of a new password by 711 decreasing the length of the current password. For example, a client 712 with a 20 character password set using the extension, should not use 713 the login command in [RFC5730] without using the extension, to set a 714 new password that is less than or equal to 16 characters. 716 The extension provides an extensible list of login security events to 717 inform clients of connection and login warnings and errors. 719 9. Acknowledgements 721 The authors wish to thank the following persons for their feedback 722 and suggestions: 724 o Patrick Mevzek 725 o Scott Hollenbeck 727 10. References 729 10.1. Normative References 731 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 732 Requirement Levels", BCP 14, RFC 2119, 733 DOI 10.17487/RFC2119, March 1997, . 736 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 737 DOI 10.17487/RFC3688, January 2004, . 740 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 741 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 742 . 744 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 745 Code: The Implementation Status Section", BCP 205, 746 RFC 7942, DOI 10.17487/RFC7942, July 2016, 747 . 749 [W3C.REC-xmlschema-2-20041028] 750 Biron, P. and A. Malhotra, "XML Schema Part 2: Datatypes 751 Second Edition", World Wide Web Consortium Recommendation 752 REC-xmlschema-2-20041028, October 2004, 753 . 755 10.2. Informative References 757 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 758 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 759 February 2015, . 761 10.3. URIs 763 [1] https://pages.nist.gov/800-63-3/sp800-63b.html 765 Appendix A. Change History 767 A.1. Change from 00 to 01 769 1. Based on the feedback from Patrick Mevzek and a proposal from 770 Scott Hollenbeck, changed the minimum length of the password from 771 8 to 6, revised the description of the password, and added text 772 in the Security Considerations section for the server password 773 length policy. 775 A.2. Change from 01 to 02 777 1. Changed the XML namespace from urn:ietf:params:xml:ns:loginSec- 778 0.3 to urn:ietf:params:xml:ns:epp:loginSec-0.3, and changed the 779 XML schema registration from urn:ietf:params:xml:ns:loginSec-0.3 780 to urn:ietf:params:xml:schema:epp:loginSec-0.3 based on a request 781 from IANA with draft-ietf-regext-allocation-token. 783 A.3. Change from 02 to 03 785 Updates based on the review by Patrick Mevzek, that include: 787 1. Fix the inconsistent case for newPW, that required a global 788 change in the draft text and an update to the XML schema to 789 "urn:ietf:params:xml:ns:loginSec-0.3". 790 2. Changed "contains the following child elements" to "MUST contain 791 at least one of the following child elements", section "EPP 792 Command" to ensure that an empty 793 element is not passed. 794 3. Add "The client SHOULD NOT decrease the security of a new 795 password by decreasing the length of the current password." along 796 with an example to the "Security Considerations" section. 798 Authors' Addresses 800 James Gould 801 VeriSign, Inc. 802 12061 Bluemont Way 803 Reston, VA 20190 804 US 806 Email: jgould@verisign.com 807 URI: http://www.verisign.com 808 Matthew Pozun 809 VeriSign, Inc. 810 12061 Bluemont Way 811 Reston, VA 20190 812 US 814 Email: mpozun@verisign.com 815 URI: http://www.verisign.com