idnits 2.17.1 draft-bwilliams-kitten-opar-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 26, 2017) is 2404 days in the past. Is this intentional? Checking references for intended status: Full Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Common Authentication Technology Next Generation B. Williams 2 Internet Draft Independent 3 Intended status: Standard September 26, 2017 4 Expires: March 2018 6 Open Password Automation Recipe (OPAR) Protocol 7 draft-bwilliams-kitten-opar-00.txt 9 Abstract 11 This document introduces the Open Password Automation Recipe (OPAR) 12 Protocol, a suggested format for providing instructions to password 13 managers programmatically that defines the valid construction of a 14 password. With password managers becoming integrated into browsers, 15 websites should be able to describe the elements of an acceptable 16 password programmatically so password management plugins can read 17 and automatically generate the best option. Without this, manual 18 intervention by the user is required when the password is too long, 19 contains invalid characters, or does not meet complexity 20 requirements. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. This document may not be modified, 26 and derivative works of it may not be created, except to publish it 27 as an RFC and to translate it into languages other than English. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF), its areas, and its working groups. Note that 31 other groups may also distribute working documents as Internet- 32 Drafts. 34 Internet-Drafts are draft documents valid for a maximum of six 35 months and may be updated, replaced, or obsoleted by other documents 36 at any time. It is inappropriate to use Internet-Drafts as 37 reference material or to cite them other than as "work in progress." 39 The list of current Internet-Drafts can be accessed at 40 http://www.ietf.org/ietf/1id-abstracts.txt 42 The list of Internet-Draft Shadow Directories can be accessed at 43 http://www.ietf.org/shadow.html 45 This Internet-Draft will expire on March 26, 2018. 47 Copyright Notice 49 Copyright (c) 2017 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with 57 respect to this document. Code Components extracted from this 58 document must include Simplified BSD License text as described in 59 Section 4.e of the Trust Legal Provisions and are provided without 60 warranty as described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction......................................................3 65 2. Conventions used in this document.................................4 66 3. Construction of OPAR Policy.......................................4 67 3.1. OPAR_Policy - OPAR Version 1..............................4 68 3.1.1. "min_length" - Integer value.........................5 69 3.1.2. "max_length" - Integer value.........................5 70 3.1.3. "numbers" - Object...................................5 71 3.1.3.1. "allowed" - Boolean value.......................5 72 3.1.3.2. "minimum" - Integer value.......................5 73 3.1.4. "lowercase" - Object.................................5 74 3.1.4.1. "allowed" - Boolean value.......................5 75 3.1.4.2. "minimum" - Integer value.......................5 76 3.1.5. "uppercase" - Object.................................6 77 3.1.5.1. "allowed" - Boolean value.......................6 78 3.1.5.2. "minimum" - Integer value.......................6 79 3.1.6. "special_characters" - Object........................6 80 3.1.6.1. "allowed" - Boolean value.......................6 81 3.1.6.2. "valid_characters" - String value...............6 82 3.1.6.3. "minimum" - Integer value.......................6 83 3.1.7. "wide_characters" - Object...........................6 84 3.1.7.1. "allowed" - Boolean value.......................7 85 3.1.7.2. "minimum" - Integer value.......................7 86 3.1.8. "include_extended_ascii" - Boolean value.............7 87 3.2. Examples..................................................7 88 3.2.1. Password Recipe Example 1............................7 89 3.2.2. Password Recipe Example 1............................8 90 4. Security Considerations..........................................10 91 5. IANA Considerations..............................................10 92 6. Conclusions......................................................10 93 7. References.......................................................10 94 7.1. Normative References.....................................10 95 7.2. Informative References...................................10 96 8. Acknowledgments..................................................11 98 1. Introduction 100 Password managers are becoming the norm as both Apple and Google 101 have embedded them into their operating systems and browsers. The 102 goal addressed by password managers is to enable users to use 103 different username/password combinations on every site they visit, 104 while locally storing all of those items encrypted. When a user 105 visits a site, stored passwords are automatically presented for 106 authentication. 108 Password reuse is a known vulnerability in authentication systems 109 and can lead to identity theft[2]. With several available password 110 management systems such as 1Password, LastPass, and the Apple 111 Keychain, a standardized, programmatic way to read the password 112 policy of a website would further automate these applications. 113 Password managers embed functionality into popular browsers to 114 suggest secure passwords and manage them across devices. 116 The challenge with password generation is that not all sites use the 117 same requirements to create a password, and individuals will often 118 not maximize the strength of a new password as they take the default 119 suggested value. As an example, a site that suggests a password of 120 8-20 characters might receive "9ay-mgr-3PO-iaa" from a password 121 manager, five characters short of the maximum. In addition, the site 122 may not permit hyphens in passwords, yet still require a special 123 character. Users would need to randomly create one to comply with 124 the standard. 126 This document proposes the Open Password Automation Recipe (OPAR) 127 Protocol as a way to define valid password recipes for password 128 managers while improving user experience. OPAR is a simple protocol 129 that can be implemented on any page where password generation is 130 required (such as a sign up or change password page) to inform 131 password managers of the acceptable format for a valid password. 132 Then the password manager can suggest and fill in the strongest 133 possible password without requiring user intervention to tweak the 134 recipe. 136 Implementing and Executing the OPAR Protocol: 138 1. Site operator adds markup or JSON in the format below to pages 139 requiring password automation. 141 2. Password manager interprets format to automatically suggest a 142 password that maximizes password strength according to the 143 recipe. 145 3. Submit the password while storing credentials inside the password 146 manager. 148 2. Conventions used in this document 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 151 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 152 document are to be interpreted as described in RFC 2119[1]. 154 In this document, these words will appear with that interpretation 155 only when in ALL CAPS. Lower case uses of these words are not to be 156 interpreted as carrying significance described in RFC 2119. 158 In this document, the characters ">>" preceding an indented line(s) 159 indicates a statement using the key words listed above. This 160 convention aids reviewers in quickly identifying or finding the 161 portions of this RFC covered by these keywords. 163 3. Construction of OPAR Policy 165 This section defines the construction of a JSON object that declares 166 the options in the OPAR protocol. 168 3.1. OPAR_Policy - OPAR Version 1 170 The JSON object that stores the OPAR values MUST be named 171 OPAR_Policy. This object SHOULD be included only on the new password 172 and change password pages. 174 The first element in the JSON object MUST be named "version" with an 175 integer value corresponding to the value of the protocol. The only 176 value that is acceptable at this time is 1, but future versions of 177 the protocol may add additional features. 179 All of the elements below MUST be included in the OPAR object 180 definition to be considered a valid implementation of version 1 of 181 the protocol. Some elements, however, MAY be listed at 0 (say for 182 example if there is no minimum number of special characters), but 183 the element MUST be present in the object. 185 The following sub-sections describe the remainder of the OPAR record 186 options available in version 1 of the OPAR protocol. 188 3.1.1. "min_length" - Integer value 190 Password recipes require a minimum length to be valid. The integer 191 value in this field represents the absolute minimum number of 192 characters required for a valid password. 194 3.1.2. "max_length" - Integer value 196 The integer value here should be the maximum number of characters 197 allowed. Password managers should focus on this value and elect to 198 fill every available position in the password with a character. 200 3.1.3. "numbers" - Object 202 The numbers object will define the options for numbers in the 203 password recipe. 205 3.1.3.1. "allowed" - Boolean value 207 If numbers are allowed, set the value to true. If not, set the value 208 to false. 210 3.1.3.2. "minimum" - Integer value 212 If numbers are required, enter the minimum amount of single digit 213 integers that will constitute a valid password. If numbers are 214 allowed but not required, set this value to 0. 216 3.1.4. "lowercase" - Object 218 The lowercase object will define the options for lowercase letters 219 in the password recipe. 221 3.1.4.1. "allowed" - Boolean value 223 If lowercase letters are allowed, set the value to true. If not, set 224 the value to false. 226 3.1.4.2. "minimum" - Integer value 228 If lowercase letters are required, enter the minimum amount of 229 single digit lowercase characters that will constitute a valid 230 password. If lowercase letters are allowed but not required, set 231 this value to 0. 233 3.1.5. "uppercase" - Object 235 The uppercase object will define the options for uppercase letters 236 in the password recipe. 238 3.1.5.1. "allowed" - Boolean value 240 If uppercase letters are allowed, set the value to true. If not, set 241 the value to false. 243 3.1.5.2. "minimum" - Integer value 245 If uppercase letters are required, enter the minimum amount of 246 single digit uppercase characters that will constitute a valid 247 password. If uppercase letters are allowed but not required, set 248 this value to 0. 250 3.1.6. "special_characters" - Object 252 The special_characters object will define the options for special 253 characters in the password recipe. 255 3.1.6.1. "allowed" - Boolean value 257 If special characters are allowed, set the value to true. If not, 258 set the value to false. 260 3.1.6.2. "valid_characters" - String value 262 A single string value that contains one of every special character. 263 This should be represented as a set of valid special characters that 264 make up a password. Only include special characters that may be used 265 in the password. Remember to escape double quotes if that character 266 is allowed. 268 3.1.6.3. "minimum" - Integer value 270 If special characters are required, enter the minimum amount of 271 single digit special characters that will constitute a valid 272 password. If special characters are allowed but not required, set 273 this value to 0. 275 3.1.7. "wide_characters" - Object 277 Some locales may require or desire the use of so called wide or 278 multibyte characters. This object will define the options for wide 279 characters in the password recipe. 281 3.1.7.1. "allowed" - Boolean value 283 If wide characters are allowed, set the value to true. If not, set 284 the value to false. 286 3.1.7.2. "minimum" - Integer value 288 If wide characters are required, enter the minimum amount of single 289 digit wide characters that will constitute a valid password. If wide 290 characters are allowed but not required, set this value to 0. 292 3.1.8. "include_extended_ascii" - Boolean value 294 Some locales may leverage characters from the extended ASCII 295 character set, such as Cyrillic, accented Western characters, and 296 Greek characters. If you want to allow these characters, set this 297 value to true. There are no minimums here as these would simply 298 extend the uppercase and lowercase character sets. 300 3.2. Examples 302 The following sections provide two examples of JSON objects that 303 define a password recipe. 305 3.2.1. Password Recipe Example 1 307 The following OPAR password recipe defines a valid password that 308 must be at least 8 characters, but no more than 20, with numbers, 309 lowercase letters, and uppercase letters all allowed (minimum two of 310 each), and only these special characters allowed (+ - _ ( ) * & ^ % 311 $ # @ ! ?), minimum 2. No wide characters are allowed, but the 312 extended ASCII set is permitted. 314 { 316 "version":1, 318 "min_length":8, 320 "max_length":20, 322 "numbers":{ 324 "allowed": true, 326 "minimum": 2 328 }, 330 "lowercase":{ 332 "allowed": true, 334 "minimum": 2 336 }, 338 "uppercase":{ 340 "allowed": true, 342 "minimum": 2 344 }, 346 "special_characters":{ 348 "allowed": true, 350 "valid_characters": "+-_()*&^%$#@!?", 352 "minimum": 2 354 }, 356 "wide_characters":{ 358 "allowed": false, 360 "minimum": 0 362 }, 364 "include_extended_ascii": true 366 } 368 3.2.2. Password Recipe Example 1 370 The following OPAR password recipe defines a valid password that 371 must be at least 6 characters, but no more than 12, with numbers, 372 lowercase letters, and uppercase letters only allowed (minimum one 373 of each). No special characters, extended ASCII, or wide characters 374 are permitted. 376 { 378 "version":1, 380 "min_length":6, 382 "max_length":12, 384 "numbers":{ 386 "allowed": true, 388 "minimum": 1 390 }, 392 "lowercase":{ 394 "allowed": true, 396 "minimum": 1 398 }, 400 "uppercase":{ 402 "allowed": true, 404 "minimum": 1 406 }, 408 "special_characters":{ 410 "allowed": false, 412 "valid_characters": null, 414 "minimum": 0 416 }, 418 "wide_characters":{ 420 "allowed": false, 422 "minimum": 0 424 }, 426 "include_extended_ascii": false 428 } 430 4. Security Considerations 432 In order for the recipes to be effective, site managers must ensure 433 that the recipe promotes the maximum password complexity possible. 434 Ideally, two things should happen. Site managers should review 435 existing password storage capabilities to maximize the strength of 436 new passwords, and recipes should mirror the instructions given to 437 users in English on how to construct a secure password. 439 Password managers should focus on the largest effective strength of 440 password based on the maximum allowed character positions given the 441 defined acceptable keyspace (allowed characters) to provide maximum 442 password effectiveness[3]. 444 5. IANA Considerations 446 No IANA considerations required. 448 6. Conclusions 450 The OPAR Protocol is designed to improve automation and usability of 451 password managers used by individuals at large. Through this 452 additional automation, users will not have to fight password 453 managers and may more readily adopt them as their user experience 454 improves. 456 7. References 458 7.1. Normative References 460 [1] Bradner, S., "Key words for use in RFCs to Indicate 461 Requirement Levels", BCP 14, RFC 2119, March 1997. 463 7.2. Informative References 465 [2] Gaw, S., & Felten, E. W. (2006, July). Password management 466 strategies for online accounts. In Proceedings of the second 467 symposium on Usable privacy and security (pp. 44-55). ACM. 469 [3] O'Gorman, L. (2003). Comparing passwords, tokens, and 470 biometrics for user authentication. Proceedings of the IEEE, 471 91(12), 2021-2040. 473 8. Acknowledgments 475 Special thanks to Matt Springfield for being a sounding board. 477 This document was prepared using 2-Word-v2.0.template.dot. 479 Authors' Addresses 480 Branden Williams 481 Independent 482 2450 Lakeside Parkway 483 Suite 150-1026 484 Flower Mound TX 75022 486 Email: ietf@brandenwilliams.com