idnits 2.17.1 draft-gould-regext-login-security-policy-00.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 (September 12, 2018) is 2053 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 660 -- Looks like a reference, but probably isn't: '2' on line 662 == Outdated reference: A later version (-04) exists of draft-gould-carney-regext-registry-03 == Outdated reference: A later version (-03) exists of draft-gould-regext-login-security-02 Summary: 0 errors (**), 0 flaws (~~), 3 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 September 12, 2018 5 Expires: March 16, 2019 7 Login Security Policy Extensions Mapping for the Extensible Provisioning 8 Protocol (EPP) 9 draft-gould-regext-login-security-policy-00 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 March 16, 2019. 36 Copyright Notice 38 Copyright (c) 2018 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 . . . . . . . . . . . . . . . . . 7 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 7. Security Considerations . . . . . . . . . . . . . . . . . . . 13 77 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 78 9. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 9.1. Normative References . . . . . . . . . . . . . . . . . . 14 80 9.2. Informative References . . . . . . . . . . . . . . . . . 14 81 9.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 15 82 Appendix A. Change History . . . . . . . . . . . . . . . . . . . 15 83 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . 15 85 1. Introduction 87 This document describes an extension mapping for version 1.0 of the 88 Extensible Provisioning Protocol (EPP) [RFC5730]. This document 89 describes an extension of the Registry Mapping 90 [I-D.gould-carney-regext-registry] to define the server policy of the 91 Login Security EPP extension [I-D.gould-regext-login-security] for a 92 registry system. 94 1.1. Conventions Used in This Document 96 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 97 "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and 98 "OPTIONAL" in this document are to be interpreted as described in BCP 99 14 [RFC2119] [RFC8174] when, and only when, they appear in all 100 capitals, as shown here. 102 XML is case sensitive. Unless stated otherwise, XML specifications 103 and examples provided in this document MUST be interpreted in the 104 character case presented in order to develop a conforming 105 implementation. 107 In examples, "C:" represents lines sent by a protocol client and "S:" 108 represents lines returned by a protocol server. Indentation and 109 white space in examples are provided only to illustrate element 110 relationships and are not a REQUIRED feature of this protocol. 112 The XML namespace prefix "loginSecPolicy" is used for the namespace 113 "urn:ietf:params:xml:ns:epp:loginSecPolicy-0.1", but implementations 114 MUST NOT depend on it and instead employ a proper namespace-aware XML 115 parser and serializer to interpret and output the XML documents. 117 The XML namespace prefix "loginSec" is used for the namespace 118 "urn:ietf:params:xml:ns:loginSec-0.1", as defined in 119 [I-D.gould-regext-login-security], but implementations MUST NOT 120 depend on it and instead employ a proper namespace-aware XML parser 121 and serializer to interpret and output the XML documents. 123 2. Object Attributes 125 An EPP login security policy has attributes and associated values 126 that may be viewed and modified by the sponsoring client or the 127 server. This section describes each attribute type in detail. The 128 formal syntax for the attribute values described here can be found in 129 the "Formal Syntax" section of this document and in the appropriate 130 normative references. 132 2.1. Dates and Times 134 Date and time attribute values MUST be represented in Universal 135 Coordinated Time (UTC) using the Gregorian calendar. The extended 136 date-time form using upper case "T" and "Z" characters defined in XML 137 Schema Part 2 [1] MUST be used to represent date-time values, as XML 138 Schema does not support truncated date-time forms or lower case "T" 139 and "Z" characters. 141 2.2. Event Types 143 The element has a REQUIRED "type" attribute 144 and an OPTIONAL "name" attribute that defines the security event 145 type. The "name" attribute is used to define a sub-type or the type 146 name when the "type" attribute is "custom". The enumerated list of 147 "type" values include: 149 "password": Identifies a password expiry event policy. 150 "certificate": Identifies a client certificate expiry event policy. 151 "cipher": Identifies an insecure or deprecated TLS cipher suite 152 event policy. 153 "tlsProtocol": Identifies an insecure or deprecated TLS protocol 154 event policy. 155 "newPw": Identifies the new password complexity requirements event 156 policy. 157 "stat": Identifies the login security statistical warning event 158 policy. The "name" attribute defines the statistic. 159 "custom": Identifies a custom event type that MUST set the "name" 160 attribute with the custom event type name. 162 2.3. System Object 164 The System object, represented by the element in 165 the Registry Mapping [I-D.gould-carney-regext-registry], is the 166 object that is extended by this extension with the 167 element. The element 168 contains the following child elements: 170 : The login password format policy. The 171 element contains the following child 172 elements: 174 : The login password format 175 regular expression. The regular expression MUST conform 176 to the Perl-compatible Regular Expression (PCRE) [pcre] 177 syntax. Programming languages support different sets of 178 PCRE features, so the server SHOULD define a PCRE that 179 leverages features that are supported by a broad set of 180 client programming languages. 181 : The OPTIONAL human readable 182 description of the login password format policy. The 183 "lang" attribute MAY be present to identify the language 184 of the description if the negotiated value is something 185 other than the default value of "en" (English). 187 : OPTIONAL boolean value that 188 indicates the server supports the 189 element, with the default value of "0" (or "false"). A value 190 of "1" (or "true") means that the server processes the 191 element. A value of "0" (or "false") 192 means that the server ignores the element 193 if passed by the client. 194 : Zero or more 195 elements that defines the policies associated with the 196 supported security events. The required "type" attribute and 197 the OPTIONAL "name" attribute defines the event type, as 198 described in Section 2.2. The element 199 contains the following child elements: 201 : One or two 202 elements that indicate the possible set of event levels 203 ("warning" or "error") the server will return to the 204 client for the event type. 205 : OPTIONAL boolean element that 206 indicates whether the event type includes a 207 element with the default value of "0" 208 (or "false"). 209 : OPTIONAL duration element that the 210 event type must be reset. For example, the password will 211 expire 30 days after being set. 212 : OPTIONAL duration element 213 that indicates how long prior to expiry the server will 214 include a warning event. For example, the server will 215 include a password expiry warning event 15 days prior to 216 expiry. 217 : OPTIONAL indication of what will 218 error will occur at expiry. The possible 219 values include: 221 "connect": At expiry the client connection will fail. 222 For example, when the client certificate expires, the 223 TLS handshake will fail. 224 "login": At expiry the client login will fail. For 225 example, when the password expires, the login will 226 fail. 227 "none": At expiry there is no predefined failure action. 228 For example, when the password expires, the server 229 will not fail the login. 230 : OPTIONAL threshold value that 231 triggers a warning event for a specific "stat" event. For 232 example, a "failedLogins" "stat" warning event will occur 233 if the number of failed logins exceeds 100. 234 : OPTIONAL period value that is 235 associated with a warning event for a specific "stat" 236 event. For example, a "failedLogins" "stat" warning event 237 will occur if the number of failed logins exceeds the 238 value over a period of 1 day. 240 Example of a element that defines the 241 password policy and the policy of each of the supported login 242 security events: 244 245 246 247 (?=.*\d) 248 (?=.*[a-zA-Z]) 249 (?=.*[\x21-\x2F\x3A-\x40\x5B-\x60\x7B-\x7E]) 250 (?!^\s+) 251 (?!.*\s+$) 252 (?!.*\s{2,}) 253 ^[\x20-\x7e]{16,128}$ 254 255 256 16 to 128 printable characters (alphanumeric, space, and 257 special characters) with at least one number, letter, and 258 special character, with no leading or trailing whitespace, 259 and with no consecutive spaces. 260 261 262 true 263 264 265 warning 266 error 267 true 268 P90D 269 P15D 270 login 271 272 274 warning 275 error 276 true 277 P15D 278 connect 279 280 282 warning 283 false 284 285 287 warning 288 false 289 290 292 warning 293 false 294 100 295 P1D 296 297 299 warning 300 false 301 302 304 3. EPP Command Mapping 306 A detailed description of the EPP syntax and semantics can be found 307 in the EPP core protocol specification [RFC5730]. The command 308 mappings described here are specifically for use in provisioning and 309 managing login security policy via EPP. 311 3.1. EPP Query Commands 313 EPP [RFC5730] provides three commands to retrieve object information: 314 to determine if an object is known to the server, to 315 retrieve detailed information associated with an object, and 316 to retrieve object transfer status information. 318 3.1.1. EPP Command 320 This extension does not define any extension of the EPP 321 command or response described in the Registry Mapping. 323 3.1.2. EPP Command 325 This extension does not add any elements to the EPP command 326 described in the Registry Mapping [I-D.gould-carney-regext-registry]. 328 However, additional elements are defined for the response to a 329 query for the registry system attributes. 331 When an command has been processed successfully, the EPP 332 element MUST contain a child elements as described in the 333 Registry Mapping [I-D.gould-carney-regext-registry]. In addition, 334 the EPP element SHOULD contain a child 335 element that identifies the extension namespace if the system object 336 has data associated with this extension and based on server policy. 337 The element contains the following child 338 elements: 340 : Element that contains the full set of login security 341 policy attributes for the system as defined in Section 2.3. 343 Example response to query for the registry system attributes 344 including the login security policy attributes: 346 S: 347 S: 348 S: 349 S: 350 S: Command completed successfully 351 S: 352 S: 353 S: 355 S: ... 356 S: 357 S: 358 S: 359 S: 362 S: ... 363 S: 364 S: 365 S: 366 S: ABC-12345 367 S: 54322-XYZ 368 S: 369 S: 370 S: 372 3.1.3. EPP Query Command 374 Transfer semantics do not directly apply to system objects, so there 375 is no extension defined for the EPP query command. 377 3.2. EPP Transform Commands 379 EPP provides five commands to transform objects: to create 380 an instance of an object, to delete an instance of an 381 object, to extend the validity period of an object, 382 to manage object sponsorship changes, and to 383 change information associated with an object. 385 3.2.1. EPP Command 387 This extension does not add any elements to the EPP command 388 or response described in the Registry Mapping. 390 3.2.2. EPP Command 392 This extension does not add any elements to the EPP command 393 or response described in the Registry Mapping. 395 3.2.3. EPP Command 397 Renew semantics do not directly apply to system objects, so there is 398 no extension defined for the EPP command. 400 3.2.4. EPP Command 402 Transfer semantics do not directly apply to system objects, so there 403 is no extension defined for the EPP command. 405 3.2.5. EPP Command 407 This extension does not add any elements to the EPP command 408 or response described in the Registry Mapping. 410 4. Formal Syntax 412 One schema presented here is the EPP Login Security Policy Schema. 414 The formal syntax presented here is a complete schema representation 415 of the object mapping suitable for automated validation of EPP XML 416 instances. The BEGIN and END tags are not part of the schema; they 417 are used to note the beginning and ending of the schema for URI 418 registration purposes. 420 4.1. Launch Policy Schema 422 BEGIN 423 424 429 430 Extensible Provisioning Protocol v1.0 431 Login Security Policy Extension Schema. 432 433 436 438 441 442 443 445 446 447 450 451 452 454 456 459 460 461 462 463 465 466 467 468 469 471 472 473 474 475 476 477 478 479 482 484 486 488 490 492 494 495 497 499 500 503 504 505 506 507 508 509 510 511 512 513 514 518 519 520 521 522 523 524 527 528 529 530 531 532 533 534 537 538 END 540 5. IANA Considerations 542 5.1. XML Namespace 544 This document uses URNs to describe XML namespaces and XML schemas 545 conforming to a registry mechanism described in [RFC3688]. 547 Registration request for the login security policy namespace: 549 URI: urn:ietf:params:xml:ns:epp:loginSecPolicy-0.1 550 Registrant Contact: IESG 551 XML: None. Namespace URIs do not represent an XML specification. 553 Registration request for the login security policy XML schema: 555 URI: urn:ietf:params:xml:schema:epp:loginSecPolicy-0.1 556 Registrant Contact: IESG 557 XML: See the "Formal Syntax" section of this document. 559 5.2. EPP Extension Registry 561 The EPP extension described in this document should be registered by 562 the IANA in the EPP Extension Registry described in [RFC7451]. The 563 details of the registration are as follows: 565 Name of Extension: "Login Security Policy Extensions Mapping for the 566 Extensible Provisioning Protocol (EPP)" 568 Document status: Standards Track 570 Reference: (insert reference to RFC version of this document) 572 Registrant Name and Email Address: IESG, 574 TLDs: Any 576 IPR Disclosure: None 578 Status: Active 580 Notes: None 582 6. Implementation Status 584 TBD 586 7. Security Considerations 588 The mapping extensions described in this document provide additional 589 security services beyond those described by EPP [RFC5730] and 590 protocol layers used by EPP. The security considerations described 591 in these other specifications apply to this specification as well. 593 This mapping does define the login security policy of the server, 594 where there are security considerations with defining the policy, 595 which include: 597 1. The server SHOULD follow login password complexity best 598 practices, such as the NIST Special Publication 800-63B [2]. 599 2. The server MAY have a login password expiry that requires the 600 client to regularly change the login password. 601 3. The server SHOULD inform the client of the expiry of the login 602 password. 603 4. The server MUST store the login password at rest securely, such 604 as hashing or encrypting the login password. 605 5. The server SHOULD deprecate and eliminate insecure ciphers and 606 protocols. 607 6. The server SHOULD inform the client of the use of insecure 608 ciphers and protocols. 609 7. The server SHOULD inform the client of an expiring client 610 certificate. 612 8. Acknowledgements 614 TBD 616 9. References 618 9.1. Normative References 620 [I-D.gould-carney-regext-registry] 621 Gould, J., Jia, L., Carney, R., and J. Kolker, "Registry 622 Mapping for the Extensible Provisioning Protocol (EPP)", 623 draft-gould-carney-regext-registry-03 (work in progress), 624 August 2018. 626 [I-D.gould-regext-login-security] 627 Gould, J. and M. Pozun, "Login Security Extension for the 628 Extensible Provisioning Protocol (EPP)", draft-gould- 629 regext-login-security-02 (work in progress), August 2018. 631 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 632 Requirement Levels", BCP 14, RFC 2119, 633 DOI 10.17487/RFC2119, March 1997, . 636 [RFC3688] Mealling, M., "The IETF XML Registry", BCP 81, RFC 3688, 637 DOI 10.17487/RFC3688, January 2004, . 640 [RFC5730] Hollenbeck, S., "Extensible Provisioning Protocol (EPP)", 641 STD 69, RFC 5730, DOI 10.17487/RFC5730, August 2009, 642 . 644 9.2. Informative References 646 [pcre] Hazel, P., "Perl-compatible Regular Expressions (PCRE)", 647 October 2016, . 650 [RFC7451] Hollenbeck, S., "Extension Registry for the Extensible 651 Provisioning Protocol", RFC 7451, DOI 10.17487/RFC7451, 652 February 2015, . 654 [RFC8174] Leiba, B., "Ambiguity of Uppercase vs Lowercase in RFC 655 2119 Key Words", BCP 14, RFC 8174, DOI 10.17487/RFC8174, 656 May 2017, . 658 9.3. URIs 660 [1] http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/ 662 [2] https://pages.nist.gov/800-63-3/sp800-63b.html 664 Appendix A. Change History 666 Author's Address 668 James Gould 669 VeriSign, Inc. 670 12061 Bluemont Way 671 Reston, VA 20190 672 US 674 Email: jgould@verisign.com 675 URI: http://www.verisigninc.com