idnits 2.17.1 draft-gould-regext-login-security-policy-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 (August 2, 2019) is 1722 days in the past. Is this intentional? 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 775 -- Looks like a reference, but probably isn't: '2' on line 777 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 VeriSign, Inc. 4 Intended status: Standards Track August 2, 2019 5 Expires: February 3, 2020 7 Login Security Policy Extensions Mapping for the Extensible Provisioning 8 Protocol (EPP) 9 draft-gould-regext-login-security-policy-03 11 Abstract 13 This document describes an Extensible Provisioning Protocol (EPP) 14 extension of the Registry Mapping to define the server policy of the 15 Login Security EPP extension. The server policy of the Login 16 Security EPP extension includes the MAYs, SHOULDs, and options 17 implemented by the server. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at https://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on February 3, 2020. 36 Copyright Notice 38 Copyright (c) 2019 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (https://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 54 1.1. Conventions Used in This Document . . . . . . . . . . . . 3 55 2. Object Attributes . . . . . . . . . . . . . . . . . . . . . . 3 56 2.1. Dates and Times . . . . . . . . . . . . . . . . . . . . . 3 57 2.2. Event Types . . . . . . . . . . . . . . . . . . . . . . . 4 58 2.3. System Object . . . . . . . . . . . . . . . . . . . . . . 4 59 3. EPP Command Mapping . . . . . . . . . . . . . . . . . . . . . 8 60 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 8 61 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 8 62 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 63 3.1.3. EPP Query Command . . . . . . . . . . . . 10 64 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 10 65 3.2.1. EPP Command . . . . . . . . . . . . . . . . 10 66 3.2.2. EPP Command . . . . . . . . . . . . . . . . 10 67 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 10 68 3.2.4. EPP Command . . . . . . . . . . . . . . . 10 69 3.2.5. EPP Command . . . . . . . . . . . . . . . . 10 70 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 10 71 4.1. Login Security Policy Schema . . . . . . . . . . . . . . 11 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 13 74 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 14 75 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 14 76 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 15 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 15 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 16 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 16 81 9.2. Informative References . . . . . . . . . . . . . . . . . 17 82 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 17 83 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 17 84 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 17 85 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 17 86 A.3. Change from 02 to 03 . . . . . . . . . . . . . . . . . . 17 87 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 18 89 1. Introduction 91 This document describes an extension mapping for version 1.0 of the 92 Extensible Provisioning Protocol (EPP) [RFC5730]. This document 93 describes an extension of the Registry Mapping 94 [I-D.gould-carney-regext-registry] to define the server policy of the 95 Login Security EPP extension [I-D.gould-regext-login-security] for a 96 registry system. 98 1.1. Conventions Used in This Document 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 102 "OPTIONAL" in this document are to be interpreted as described in BCP 103 14 [RFC2119] [RFC8174] when, and only when, they appear in all 104 capitals, as shown here. 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 The XML namespace prefix "loginSecPolicy" is used for the namespace 117 "urn:ietf:params:xml:ns:epp:loginSecPolicy-0.4", but implementations 118 MUST NOT depend on it and instead employ a proper namespace-aware XML 119 parser and serializer to interpret and output the XML documents. 121 The XML namespace prefix "loginSec" is used for the namespace 122 "urn:ietf:params:xml:ns:loginSec-0.1", as defined in 123 [I-D.gould-regext-login-security], but implementations MUST NOT 124 depend on it and instead employ a proper namespace-aware XML parser 125 and serializer to interpret and output the XML documents. 127 2. Object Attributes 129 An EPP login security policy has attributes and associated values 130 that may be viewed and modified by the sponsoring client or the 131 server. This section describes each attribute type in detail. The 132 formal syntax for the attribute values described here can be found in 133 the "Formal Syntax" section of this document and in the appropriate 134 normative references. 136 2.1. Dates and Times 138 Date and time attribute values MUST be represented in Universal 139 Coordinated Time (UTC) using the Gregorian calendar. The extended 140 date-time form using upper case "T" and "Z" characters defined in XML 141 Schema Part 2 [1] MUST be used to represent date-time values, as XML 142 Schema does not support truncated date-time forms or lower case "T" 143 and "Z" characters. 145 2.2. Event Types 147 The element has a REQUIRED "type" attribute 148 and an OPTIONAL "name" attribute that defines the security event 149 type. The "name" attribute is used to define a sub-type or the type 150 name when the "type" attribute is "custom". The enumerated list of 151 "type" values include: 153 "password": Identifies a password expiry event policy. 154 "certificate": Identifies a client certificate expiry event policy. 155 "cipher": Identifies an insecure or deprecated TLS cipher suite 156 event policy. 157 "tlsProtocol": Identifies an insecure or deprecated TLS protocol 158 event policy. 159 "newPW": Identifies the new password complexity requirements event 160 policy. 161 "stat": Identifies the login security statistical warning event 162 policy. The "name" attribute defines the statistic. 163 "custom": Identifies a custom event type that MUST set the "name" 164 attribute with the custom event type name. 166 2.3. System Object 168 The System object, represented by the element in 169 the Registry Mapping [I-D.gould-carney-regext-registry], is the 170 object that is extended by this extension with the 171 element. The element 172 contains the following child elements: 174 : The login password format policy. The 175 element contains the following child 176 elements: 178 : The login password format 179 regular expression. The regular expression MUST conform 180 to the Perl-compatible Regular Expression (PCRE) [pcre] 181 syntax. Programming languages support different sets of 182 PCRE features, so the server SHOULD define a PCRE that 183 leverages features that are supported by a broad set of 184 client programming languages. 185 : The OPTIONAL human readable 186 description of the login password format policy. The 187 "lang" attribute MAY be present to identify the language 188 of the description if the negotiated value is something 189 other than the default value of "en" (English). 190 : The OPTIONAL boolean element, 191 with a default value of "false", that indicates additional 192 special format rules apply that cannot be represented in 193 the regular expression. A value of "1" (or "true") means 194 that special format rules do apply that MUST be described 195 in the element for manual 196 review. The server SHOULD represent the most specific 197 regular expression possible with the 198 element. A value of "0" (or 199 "false") means that the 200 element fully represents the format requirements. 201 : The OPTIONAL boolean 202 element, with a default value of "false", that indicates 203 that the server has a list of restricted words that cannot 204 be used in the password. The optional "url" attribute 205 references a description of the list of restricted words. 206 : OPTIONAL boolean value that 207 indicates the server supports the 208 element, with the default value of "0" (or "false"). A value 209 of "1" (or "true") means that the server processes the 210 element. A value of "0" (or "false") 211 means that the server ignores the element 212 if passed by the client. 213 : Zero or more 214 elements that defines the policies associated with the 215 supported security events. The required "type" attribute and 216 the OPTIONAL "name" attribute defines the event type, as 217 described in Section 2.2. The element 218 contains the following child elements: 220 : One or two 221 elements that indicate the possible set of event levels 222 ("warning" or "error") the server will return to the 223 client for the event type. 224 : OPTIONAL boolean element that 225 indicates whether the event type includes a 226 element with the default value of "0" 227 (or "false"). 228 : OPTIONAL duration element that the 229 event type must be reset. For example, the password will 230 expire 30 days after being set. 231 : OPTIONAL duration element 232 that indicates how long prior to expiry the server will 233 include a warning event. For example, the server will 234 include a password expiry warning event 15 days prior to 235 expiry. 236 : OPTIONAL indication of what 237 action will occur with an error, including at expiry when 238 is "1" (or "true"). The possible 239 values include: 241 "connect": The client connection will fail. For example, 242 when the client certificate expires, the TLS handshake 243 will fail. 244 "login": The client login will fail. For example, when 245 the new password does not meet the server password 246 complexity requirements or when the password expires, 247 the login will fail. 248 "none": There is no predefined failure action. For 249 example, when the password expires, the server will 250 not fail the login. 251 : OPTIONAL threshold value that 252 triggers a warning event for a specific "stat" event. For 253 example, a "failedLogins" "stat" warning event will occur 254 if the number of failed logins exceeds 100. 255 : OPTIONAL period value that is 256 associated with a warning event for a specific "stat" 257 event. For example, a "failedLogins" "stat" warning event 258 will occur if the number of failed logins exceeds the 259 value over a period of 1 day. 261 Example of a element that defines the 262 password policy and the policy of each of the supported login 263 security events: 265 266 267 268 (?=.*\d) 269 (?=.*[a-zA-Z]) 270 (?=.*[\x21-\x2F\x3A-\x40\x5B-\x60\x7B-\x7E]) 271 (?!^\s+) 272 (?!.*\s+$) 273 (?!.*\s{2,}) 274 ^[\x20-\x7e]{16,32}$ 275 276 277 16 to 32 printable characters (alphanumeric, space, and 278 special characters) with at least one number, letter, and 279 special character, with no leading or trailing whitespace, 280 and with no consecutive spaces. 282 283 false 284 285 287 true 288 289 290 true 291 292 293 error 294 295 login 296 297 298 299 warning 300 301 error 302 303 true 304 305 P90D 306 307 P15D 308 309 login 310 311 312 313 warning 314 315 error 316 317 true 318 319 P15D 320 321 connect 322 323 324 325 warning 326 327 false 328 329 330 331 warning 332 333 false 334 335 336 337 warning 338 339 false 340 341 100 342 343 P1D 344 345 346 347 warning 348 349 false 350 351 352 354 3. EPP Command Mapping 356 A detailed description of the EPP syntax and semantics can be found 357 in the EPP core protocol specification [RFC5730]. The command 358 mappings described here are specifically for use in provisioning and 359 managing login security policy via EPP. 361 3.1. EPP Query Commands 363 EPP [RFC5730] provides three commands to retrieve object information: 364 to determine if an object is known to the server, to 365 retrieve detailed information associated with an object, and 366 to retrieve object transfer status information. 368 3.1.1. EPP Command 370 This extension does not define any extension of the EPP 371 command or response described in the Registry Mapping. 373 3.1.2. EPP Command 375 This extension does not add any elements to the EPP command 376 described in the Registry Mapping [I-D.gould-carney-regext-registry]. 378 However, additional elements are defined for the response to a 379 query for the registry system attributes. 381 When an command has been processed successfully, the EPP 382 element MUST contain a child elements as described in the 383 Registry Mapping [I-D.gould-carney-regext-registry]. In addition, 384 the EPP element SHOULD contain a child 385 element that identifies the extension namespace if the system object 386 has data associated with this extension and based on server policy. 387 The element contains the following child 388 elements: 390 : Element that contains the full set of login security 391 policy attributes for the system as defined in Section 2.3. 393 Example response to query for the registry system attributes 394 including the login security policy attributes: 396 S: 397 S: 398 S: 399 S: 400 S: Command completed successfully 401 S: 402 S: 403 S: 405 S: ... 406 S: 407 S: 408 S: 409 S: 412 S: ... 413 S: 414 S: 415 S: 416 S: ABC-12345 417 S: 54322-XYZ 418 S: 419 S: 420 S: 422 3.1.3. EPP Query Command 424 Transfer semantics do not directly apply to system objects, so there 425 is no extension defined for the EPP query command. 427 3.2. EPP Transform Commands 429 EPP provides five commands to transform objects: to create 430 an instance of an object, to delete an instance of an 431 object, to extend the validity period of an object, 432 to manage object sponsorship changes, and to 433 change information associated with an object. 435 3.2.1. EPP Command 437 This extension does not add any elements to the EPP command 438 or response described in the Registry Mapping. 440 3.2.2. EPP Command 442 This extension does not add any elements to the EPP command 443 or response described in the Registry Mapping. 445 3.2.3. EPP Command 447 Renew semantics do not directly apply to system objects, so there is 448 no extension defined for the EPP command. 450 3.2.4. EPP Command 452 Transfer semantics do not directly apply to system objects, so there 453 is no extension defined for the EPP command. 455 3.2.5. EPP Command 457 This extension does not add any elements to the EPP command 458 or response described in the Registry Mapping. 460 4. Formal Syntax 462 One schema presented here is the EPP Login Security Policy Schema. 464 The formal syntax presented here is a complete schema representation 465 of the object mapping suitable for automated validation of EPP XML 466 instances. The BEGIN and END tags are not part of the schema; they 467 are used to note the beginning and ending of the schema for URI 468 registration purposes. 470 4.1. Login Security Policy Schema 472 BEGIN 473 474 479 480 Extensible Provisioning Protocol v1.0 481 Login Security Policy Extension Schema. 482 483 486 488 491 492 493 495 496 497 500 501 502 504 506 509 510 511 512 513 515 516 517 518 519 521 522 523 524 525 529 533 534 535 536 537 538 541 542 543 544 545 546 549 551 553 555 557 559 561 562 564 567 568 571 572 573 574 575 576 577 578 579 580 581 582 585 586 587 588 589 590 591 594 595 596 597 598 599 600 601 604 605 END 607 5. IANA Considerations 609 5.1. XML Namespace 611 This document uses URNs to describe XML namespaces and XML schemas 612 conforming to a registry mechanism described in [RFC3688]. 614 Registration request for the login security policy namespace: 616 URI: urn:ietf:params:xml:ns:epp:loginSecPolicy-0.4 617 Registrant Contact: IESG 618 XML: None. Namespace URIs do not represent an XML specification. 620 Registration request for the login security policy XML schema: 622 URI: urn:ietf:params:xml:schema:epp:loginSecPolicy-0.4 623 Registrant Contact: IESG 624 XML: See the "Formal Syntax" section of this document. 626 5.2. EPP Extension Registry 628 The EPP extension described in this document should be registered by 629 the IANA in the EPP Extension Registry described in [RFC7451]. The 630 details of the registration are as follows: 632 Name of Extension: "Login Security Policy Extensions Mapping for the 633 Extensible Provisioning Protocol (EPP)" 635 Document status: Standards Track 637 Reference: (insert reference to RFC version of this document) 639 Registrant Name and Email Address: IESG, 641 TLDs: Any 643 IPR Disclosure: None 645 Status: Active 647 Notes: None 649 6. Implementation Status 651 Note to RFC Editor: Please remove this section and the reference to 652 RFC 7942 [RFC7942] before publication. 654 This section records the status of known implementations of the 655 protocol defined by this specification at the time of posting of this 656 Internet-Draft, and is based on a proposal described in RFC 7942 657 [RFC7942]. The description of implementations in this section is 658 intended to assist the IETF in its decision processes in progressing 659 drafts to RFCs. Please note that the listing of any individual 660 implementation here does not imply endorsement by the IETF. 661 Furthermore, no effort has been spent to verify the information 662 presented here that was supplied by IETF contributors. This is not 663 intended as, and must not be construed to be, a catalog of available 664 implementations or their features. Readers are advised to note that 665 other implementations may exist. 667 According to RFC 7942 [RFC7942], "this will allow reviewers and 668 working groups to assign due consideration to documents that have the 669 benefit of running code, which may serve as evidence of valuable 670 experimentation and feedback that have made the implemented protocols 671 more mature. It is up to the individual working groups to use this 672 information as they see fit". 674 6.1. Verisign EPP SDK 676 Organization: Verisign Inc. 678 Name: Verisign EPP SDK 680 Description: The Verisign EPP SDK includes both a full client 681 implementation and a full server stub implementation of draft-gould- 682 regext-login-security-policy. 684 Level of maturity: Development 686 Coverage: All aspects of the protocol are implemented. 688 Licensing: GNU Lesser General Public License 690 Contact: jgould@verisign.com 692 URL: https://www.verisign.com/en_US/channel-resources/domain- 693 registry-products/epp-sdks 695 7. Security Considerations 697 The mapping extensions described in this document provide additional 698 security services beyond those described by EPP [RFC5730] and 699 protocol layers used by EPP. The security considerations described 700 in these other specifications apply to this specification as well. 702 This mapping does define the login security policy of the server, 703 where there are security considerations with defining the policy, 704 which include: 706 1. The server SHOULD follow login password complexity best 707 practices, such as the NIST Special Publication 800-63B [2]. 708 2. The server MAY have a login password expiry that requires the 709 client to regularly change the login password. 710 3. The server SHOULD inform the client of the expiry of the login 711 password. 713 4. The server MUST store the login password at rest securely, such 714 as hashing or encrypting the login password. 715 5. The server SHOULD deprecate and eliminate insecure ciphers and 716 protocols. 717 6. The server SHOULD inform the client of the use of insecure 718 ciphers and protocols. 719 7. The server SHOULD inform the client of an expiring client 720 certificate. 722 8. Acknowledgements 724 TBD 726 9. References 728 9.1. Normative References 730 [I-D.gould-carney-regext-registry] 731 Gould, J., Jia, L., Carney, R., and J. Kolker, "Registry 732 Mapping for the Extensible Provisioning Protocol (EPP)", 733 draft-gould-carney-regext-registry-04 (work in progress), 734 October 2018. 736 [I-D.gould-regext-login-security] 737 Gould, J. and M. Pozun, "Login Security Extension for the 738 Extensible Provisioning Protocol (EPP)", draft-gould- 739 regext-login-security-03 (work in progress), January 2019. 741 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 742 Requirement Levels", BCP 14, RFC 2119, 743 DOI 10.17487/RFC2119, March 1997, 744 . 746 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 747 DOI 10.17487/RFC3688, January 2004, 748 . 750 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 751 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 752 . 754 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 755 Code: The Implementation Status Section", BCP 205, 756 RFC 7942, DOI 10.17487/RFC7942, July 2016, 757 . 759 9.2. Informative References 761 [pcre] Hazel, P., "Perl-compatible Regular Expressions (PCRE)", 762 October 2016, 763 . 765 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 766 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 767 February 2015, . 769 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 770 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 771 May 2017, . 773 9.3. URIs 775 [1] http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ 777 [2] https://pages.nist.gov/800-63-3/sp800-63b.html 779 Appendix A. Change History 781 A.1. Change from 00 to 01 783 1. Changed the element to the 784 element, to be more generic to 785 identify the action taken for an error level event for any event 786 type. The XML namespace was changed to 787 "urn:ietf:params:xml:ns:epp:loginSecPolicy-0.3" based on the 788 change to the XML schema. 789 2. Updated the Implementation Status section. 791 A.2. Change from 01 to 02 793 1. Fix the inconsistent case for newPW, that required a global 794 change in the draft text and an update to the XML schema to 795 "urn:ietf:params:xml:ns:epp:loginSecPolicy-0.3". 797 A.3. Change from 02 to 03 799 1. Added support for the and 800 elements in the 801 element to support cases where the server has 802 special format rules or restricts certain words for the password. 803 Adding the new elements resulted in updating the XML schema to 804 "urn:ietf:params:xml:ns:epp:loginSecPolicy-0.4". 806 Author's Address 808 James Gould 809 VeriSign, Inc. 810 12061 Bluemont Way 811 Reston, VA 20190 812 US 814 Email: jgould@verisign.com 815 URI: http://www.verisign.com