idnits 2.17.1 draft-gould-regext-login-security-policy-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 15, 2019) is 1928 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 710 -- Looks like a reference, but probably isn't: '2' on line 712 == Outdated reference: A later version (-03) exists of draft-gould-regext-login-security-02 Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 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 January 15, 2019 5 Expires: July 19, 2019 7 Login Security Policy Extensions Mapping for the Extensible Provisioning 8 Protocol (EPP) 9 draft-gould-regext-login-security-policy-02 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 http://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 July 19, 2019. 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 (http://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 . . . . . . . . . . . . . . . . . . . . . 7 60 3.1. EPP Query Commands . . . . . . . . . . . . . . . . . . . 7 61 3.1.1. EPP Command . . . . . . . . . . . . . . . . . 7 62 3.1.2. EPP Command . . . . . . . . . . . . . . . . . 8 63 3.1.3. EPP Query Command . . . . . . . . . . . . 9 64 3.2. EPP Transform Commands . . . . . . . . . . . . . . . . . 9 65 3.2.1. EPP Command . . . . . . . . . . . . . . . . 9 66 3.2.2. EPP Command . . . . . . . . . . . . . . . . 9 67 3.2.3. EPP Command . . . . . . . . . . . . . . . . . 9 68 3.2.4. EPP Command . . . . . . . . . . . . . . . 9 69 3.2.5. EPP Command . . . . . . . . . . . . . . . . 9 70 4. Formal Syntax . . . . . . . . . . . . . . . . . . . . . . . . 9 71 4.1. Launch Policy Schema . . . . . . . . . . . . . . . . . . 10 72 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 73 5.1. XML Namespace . . . . . . . . . . . . . . . . . . . . . . 12 74 5.2. EPP Extension Registry . . . . . . . . . . . . . . . . . 12 75 6. Implementation Status . . . . . . . . . . . . . . . . . . . . 13 76 6.1. Verisign EPP SDK . . . . . . . . . . . . . . . . . . . . 13 77 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 78 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 79 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 80 9.1. Normative References . . . . . . . . . . . . . . . . . . 15 81 9.2. Informative References . . . . . . . . . . . . . . . . . 15 82 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 16 83 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 16 84 A.1. Change from 00 to 01 . . . . . . . . . . . . . . . . . . 16 85 A.2. Change from 01 to 02 . . . . . . . . . . . . . . . . . . 16 86 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 16 88 1. Introduction 90 This document describes an extension mapping for version 1.0 of the 91 Extensible Provisioning Protocol (EPP) [RFC5730]. This document 92 describes an extension of the Registry Mapping 93 [I-D.gould-carney-regext-registry] to define the server policy of the 94 Login Security EPP extension [I-D.gould-regext-login-security] for a 95 registry system. 97 1.1. Conventions Used in This Document 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 101 "OPTIONAL" in this document are to be interpreted as described in BCP 102 14 [RFC2119] [RFC8174] when, and only when, they appear in all 103 capitals, as shown here. 105 XML is case sensitive. Unless stated otherwise, XML specifications 106 and examples provided in this document MUST be interpreted in the 107 character case presented in order to develop a conforming 108 implementation. 110 In examples, "C:" represents lines sent by a protocol client and "S:" 111 represents lines returned by a protocol server. Indentation and 112 white space in examples are provided only to illustrate element 113 relationships and are not a REQUIRED feature of this protocol. 115 The XML namespace prefix "loginSecPolicy" is used for the namespace 116 "urn:ietf:params:xml:ns:epp:loginSecPolicy-0.3", but implementations 117 MUST NOT depend on it and instead employ a proper namespace-aware XML 118 parser and serializer to interpret and output the XML documents. 120 The XML namespace prefix "loginSec" is used for the namespace 121 "urn:ietf:params:xml:ns:loginSec-0.1", as defined in 122 [I-D.gould-regext-login-security], but implementations MUST NOT 123 depend on it and instead employ a proper namespace-aware XML parser 124 and serializer to interpret and output the XML documents. 126 2. Object Attributes 128 An EPP login security policy has attributes and associated values 129 that may be viewed and modified by the sponsoring client or the 130 server. This section describes each attribute type in detail. The 131 formal syntax for the attribute values described here can be found in 132 the "Formal Syntax" section of this document and in the appropriate 133 normative references. 135 2.1. Dates and Times 137 Date and time attribute values MUST be represented in Universal 138 Coordinated Time (UTC) using the Gregorian calendar. The extended 139 date-time form using upper case "T" and "Z" characters defined in XML 140 Schema Part 2 [1] MUST be used to represent date-time values, as XML 141 Schema does not support truncated date-time forms or lower case "T" 142 and "Z" characters. 144 2.2. Event Types 146 The element has a REQUIRED "type" attribute 147 and an OPTIONAL "name" attribute that defines the security event 148 type. The "name" attribute is used to define a sub-type or the type 149 name when the "type" attribute is "custom". The enumerated list of 150 "type" values include: 152 "password": Identifies a password expiry event policy. 153 "certificate": Identifies a client certificate expiry event policy. 154 "cipher": Identifies an insecure or deprecated TLS cipher suite 155 event policy. 156 "tlsProtocol": Identifies an insecure or deprecated TLS protocol 157 event policy. 158 "newPW": Identifies the new password complexity requirements event 159 policy. 160 "stat": Identifies the login security statistical warning event 161 policy. The "name" attribute defines the statistic. 162 "custom": Identifies a custom event type that MUST set the "name" 163 attribute with the custom event type name. 165 2.3. System Object 167 The System object, represented by the element in 168 the Registry Mapping [I-D.gould-carney-regext-registry], is the 169 object that is extended by this extension with the 170 element. The element 171 contains the following child elements: 173 : The login password format policy. The 174 element contains the following child 175 elements: 177 : The login password format 178 regular expression. The regular expression MUST conform 179 to the Perl-compatible Regular Expression (PCRE) [pcre] 180 syntax. Programming languages support different sets of 181 PCRE features, so the server SHOULD define a PCRE that 182 leverages features that are supported by a broad set of 183 client programming languages. 184 : The OPTIONAL human readable 185 description of the login password format policy. The 186 "lang" attribute MAY be present to identify the language 187 of the description if the negotiated value is something 188 other than the default value of "en" (English). 190 : OPTIONAL boolean value that 191 indicates the server supports the 192 element, with the default value of "0" (or "false"). A value 193 of "1" (or "true") means that the server processes the 194 element. A value of "0" (or "false") 195 means that the server ignores the element 196 if passed by the client. 197 : Zero or more 198 elements that defines the policies associated with the 199 supported security events. The required "type" attribute and 200 the OPTIONAL "name" attribute defines the event type, as 201 described in Section 2.2. The element 202 contains the following child elements: 204 : One or two 205 elements that indicate the possible set of event levels 206 ("warning" or "error") the server will return to the 207 client for the event type. 208 : OPTIONAL boolean element that 209 indicates whether the event type includes a 210 element with the default value of "0" 211 (or "false"). 212 : OPTIONAL duration element that the 213 event type must be reset. For example, the password will 214 expire 30 days after being set. 215 : OPTIONAL duration element 216 that indicates how long prior to expiry the server will 217 include a warning event. For example, the server will 218 include a password expiry warning event 15 days prior to 219 expiry. 220 : OPTIONAL indication of what 221 action will occur with an error, including at expiry when 222 is "1" (or "true"). The possible 223 values include: 225 "connect": The client connection will fail. For example, 226 when the client certificate expires, the TLS handshake 227 will fail. 228 "login": The client login will fail. For example, when 229 the new password does not meet the server password 230 complexity requirements or when the password expires, 231 the login will fail. 232 "none": There is no predefined failure action. For 233 example, when the password expires, the server will 234 not fail the login. 236 : OPTIONAL threshold value that 237 triggers a warning event for a specific "stat" event. For 238 example, a "failedLogins" "stat" warning event will occur 239 if the number of failed logins exceeds 100. 240 : OPTIONAL period value that is 241 associated with a warning event for a specific "stat" 242 event. For example, a "failedLogins" "stat" warning event 243 will occur if the number of failed logins exceeds the 244 value over a period of 1 day. 246 Example of a element that defines the 247 password policy and the policy of each of the supported login 248 security events: 250 251 252 253 (?=.*\d) 254 (?=.*[a-zA-Z]) 255 (?=.*[\x21-\x2F\x3A-\x40\x5B-\x60\x7B-\x7E]) 256 (?!^\s+) 257 (?!.*\s+$) 258 (?!.*\s{2,}) 259 ^[\x20-\x7e]{16,128}$ 260 261 262 16 to 128 printable characters (alphanumeric, space, and 263 special characters) with at least one number, letter, and 264 special character, with no leading or trailing whitespace, 265 and with no consecutive spaces. 266 267 268 true 269 270 271 error 272 login 273 274 275 warning 276 error 277 true 278 P90D 279 P15D 280 login 281 282 283 warning 284 error 285 true 286 P15D 287 connect 288 289 290 warning 291 false 292 293 294 warning 295 false 296 297 298 warning 299 false 300 100 301 P1D 302 303 304 warning 305 false 306 307 309 3. EPP Command Mapping 311 A detailed description of the EPP syntax and semantics can be found 312 in the EPP core protocol specification [RFC5730]. The command 313 mappings described here are specifically for use in provisioning and 314 managing login security policy via EPP. 316 3.1. EPP Query Commands 318 EPP [RFC5730] provides three commands to retrieve object information: 319 to determine if an object is known to the server, to 320 retrieve detailed information associated with an object, and 321 to retrieve object transfer status information. 323 3.1.1. EPP Command 325 This extension does not define any extension of the EPP 326 command or response described in the Registry Mapping. 328 3.1.2. EPP Command 330 This extension does not add any elements to the EPP command 331 described in the Registry Mapping [I-D.gould-carney-regext-registry]. 332 However, additional elements are defined for the response to a 333 query for the registry system attributes. 335 When an command has been processed successfully, the EPP 336 element MUST contain a child elements as described in the 337 Registry Mapping [I-D.gould-carney-regext-registry]. In addition, 338 the EPP element SHOULD contain a child 339 element that identifies the extension namespace if the system object 340 has data associated with this extension and based on server policy. 341 The element contains the following child 342 elements: 344 : Element that contains the full set of login security 345 policy attributes for the system as defined in Section 2.3. 347 Example response to query for the registry system attributes 348 including the login security policy attributes: 350 S: 351 S: 352 S: 353 S: 354 S: Command completed successfully 355 S: 356 S: 357 S: 359 S: ... 360 S: 361 S: 362 S: 363 S: 366 S: ... 367 S: 368 S: 369 S: 370 S: ABC-12345 371 S: 54322-XYZ 372 S: 373 S: 374 S: 376 3.1.3. EPP Query Command 378 Transfer semantics do not directly apply to system objects, so there 379 is no extension defined for the EPP query command. 381 3.2. EPP Transform Commands 383 EPP provides five commands to transform objects: to create 384 an instance of an object, to delete an instance of an 385 object, to extend the validity period of an object, 386 to manage object sponsorship changes, and to 387 change information associated with an object. 389 3.2.1. EPP Command 391 This extension does not add any elements to the EPP command 392 or response described in the Registry Mapping. 394 3.2.2. EPP Command 396 This extension does not add any elements to the EPP command 397 or response described in the Registry Mapping. 399 3.2.3. EPP Command 401 Renew semantics do not directly apply to system objects, so there is 402 no extension defined for the EPP command. 404 3.2.4. EPP Command 406 Transfer semantics do not directly apply to system objects, so there 407 is no extension defined for the EPP command. 409 3.2.5. EPP Command 411 This extension does not add any elements to the EPP command 412 or response described in the Registry Mapping. 414 4. Formal Syntax 416 One schema presented here is the EPP Login Security Policy Schema. 418 The formal syntax presented here is a complete schema representation 419 of the object mapping suitable for automated validation of EPP XML 420 instances. The BEGIN and END tags are not part of the schema; they 421 are used to note the beginning and ending of the schema for URI 422 registration purposes. 424 4.1. Launch Policy Schema 426 BEGIN 427 428 433 434 Extensible Provisioning Protocol v1.0 435 Login Security Policy Extension Schema. 436 437 440 442 445 446 447 449 450 451 454 455 456 458 460 463 464 465 466 467 469 470 471 472 473 475 476 477 478 479 480 481 482 483 486 488 490 492 494 496 498 499 501 503 504 507 508 509 510 511 512 513 514 515 516 517 518 522 523 524 525 526 527 528 531 532 533 534 535 536 537 538 541 542 END 544 5. IANA Considerations 546 5.1. XML Namespace 548 This document uses URNs to describe XML namespaces and XML schemas 549 conforming to a registry mechanism described in [RFC3688]. 551 Registration request for the login security policy namespace: 553 URI: urn:ietf:params:xml:ns:epp:loginSecPolicy-0.3 554 Registrant Contact: IESG 555 XML: None. Namespace URIs do not represent an XML specification. 557 Registration request for the login security policy XML schema: 559 URI: urn:ietf:params:xml:schema:epp:loginSecPolicy-0.3 560 Registrant Contact: IESG 561 XML: See the "Formal Syntax" section of this document. 563 5.2. EPP Extension Registry 565 The EPP extension described in this document should be registered by 566 the IANA in the EPP Extension Registry described in [RFC7451]. The 567 details of the registration are as follows: 569 Name of Extension: "Login Security Policy Extensions Mapping for the 570 Extensible Provisioning Protocol (EPP)" 572 Document status: Standards Track 574 Reference: (insert reference to RFC version of this document) 576 Registrant Name and Email Address: IESG, 578 TLDs: Any 580 IPR Disclosure: None 582 Status: Active 584 Notes: None 586 6. Implementation Status 588 Note to RFC Editor: Please remove this section and the reference to 589 RFC 7942 [RFC7942] before publication. 591 This section records the status of known implementations of the 592 protocol defined by this specification at the time of posting of this 593 Internet-Draft, and is based on a proposal described in RFC 7942 594 [RFC7942]. The description of implementations in this section is 595 intended to assist the IETF in its decision processes in progressing 596 drafts to RFCs. Please note that the listing of any individual 597 implementation here does not imply endorsement by the IETF. 598 Furthermore, no effort has been spent to verify the information 599 presented here that was supplied by IETF contributors. This is not 600 intended as, and must not be construed to be, a catalog of available 601 implementations or their features. Readers are advised to note that 602 other implementations may exist. 604 According to RFC 7942 [RFC7942], "this will allow reviewers and 605 working groups to assign due consideration to documents that have the 606 benefit of running code, which may serve as evidence of valuable 607 experimentation and feedback that have made the implemented protocols 608 more mature. It is up to the individual working groups to use this 609 information as they see fit". 611 6.1. Verisign EPP SDK 613 Organization: Verisign Inc. 615 Name: Verisign EPP SDK 616 Description: The Verisign EPP SDK includes both a full client 617 implementation and a full server stub implementation of draft-gould- 618 regext-login-security-policy. 620 Level of maturity: Development 622 Coverage: All aspects of the protocol are implemented. 624 Licensing: GNU Lesser General Public License 626 Contact: jgould@verisign.com 628 URL: https://www.verisign.com/en_US/channel-resources/domain- 629 registry-products/epp-sdks 631 7. Security Considerations 633 The mapping extensions described in this document provide additional 634 security services beyond those described by EPP [RFC5730] and 635 protocol layers used by EPP. The security considerations described 636 in these other specifications apply to this specification as well. 638 This mapping does define the login security policy of the server, 639 where there are security considerations with defining the policy, 640 which include: 642 1. The server SHOULD follow login password complexity best 643 practices, such as the NIST Special Publication 800-63B [2]. 644 2. The server MAY have a login password expiry that requires the 645 client to regularly change the login password. 646 3. The server SHOULD inform the client of the expiry of the login 647 password. 648 4. The server MUST store the login password at rest securely, such 649 as hashing or encrypting the login password. 650 5. The server SHOULD deprecate and eliminate insecure ciphers and 651 protocols. 652 6. The server SHOULD inform the client of the use of insecure 653 ciphers and protocols. 654 7. The server SHOULD inform the client of an expiring client 655 certificate. 657 8. Acknowledgements 659 TBD 661 9. References 663 9.1. Normative References 665 [I-D.gould-carney-regext-registry] 666 Gould, J., Jia, L., Carney, R., and J. Kolker, "Registry 667 Mapping for the Extensible Provisioning Protocol (EPP)", 668 draft-gould-carney-regext-registry-04 (work in progress), 669 October 2018. 671 [I-D.gould-regext-login-security] 672 Gould, J. and M. Pozun, "Login Security Extension for the 673 Extensible Provisioning Protocol (EPP)", draft-gould- 674 regext-login-security-02 (work in progress), August 2018. 676 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 677 Requirement Levels", BCP 14, RFC 2119, 678 DOI 10.17487/RFC2119, March 1997, . 681 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 682 DOI 10.17487/RFC3688, January 2004, . 685 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 686 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 687 . 689 [RFC7942] Sheffer, Y. and A. Farrel, "Improving Awareness of Running 690 Code: The Implementation Status Section", BCP 205, 691 RFC 7942, DOI 10.17487/RFC7942, July 2016, 692 . 694 9.2. Informative References 696 [pcre] Hazel, P., "Perl-compatible Regular Expressions (PCRE)", 697 October 2016, . 700 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 701 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 702 February 2015, . 704 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 705 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 706 May 2017, . 708 9.3. URIs 710 [1] http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ 712 [2] https://pages.nist.gov/800-63-3/sp800-63b.html 714 Appendix A. Change History 716 A.1. Change from 00 to 01 718 1. Changed the element to the 719 element, to be more generic to 720 identify the action taken for an error level event for any event 721 type. The XML namespace was changed to 722 "urn:ietf:params:xml:ns:epp:loginSecPolicy-0.3" based on the 723 change to the XML schema. 724 2. Updated the Implementation Status section. 726 A.2. Change from 01 to 02 728 1. Fix the inconsistent case for newPW, that required a global 729 change in the draft text and an update to the XML schema to 730 "urn:ietf:params:xml:ns:epp:loginSecPolicy-0.3". 732 Author's Address 734 James Gould 735 VeriSign, Inc. 736 12061 Bluemont Way 737 Reston, VA 20190 738 US 740 Email: jgould@verisign.com 741 URI: http://www.verisign.com