Password Establishment Protocol

Network Working Group                                   Thomas Brownback
Request for Comments: xxxx                        Independent Researcher
Category: Experimental                                        Month YYYY

               Password Negotiation for Password Managers

Abstract

   This document proposes a protocol that would enable a password
   manager (PM) to register or change a password with online
   services. The minimal user involvement would improve the usability of
   PMs, a current hurdle in more widespread adoption. Increased use of
   PMs would improve password management by reducing the frequency of
   common, simple, reused, or rarely changed passwords online,
   significant current vulnerabilities for the web.

Status of this Memo

   This document defines an Experimental Protocol for the Internet
   community. Discussion and suggestions for improvement are requested.
   Distribution of this memo is unlimited.

Copyright Notice

   This memo is public domain by declaration of the author.

Table of Contents

   TBD

1.  Introduction

   Automated password negotiation between a password manager (PM) and an
   online account provider (OAP) would allow users to rapidly establish
   secure, unique passwords on many websites, improving password
   security on the Internet.

1.1. Password Security

   Password issues are a key source of insecurity on the Internet.

   a. Passwords must be complex to prevent attack. Passwords must also
   be memorable to allow reuse. Complexity and memorability are at odds.

   b. Password reuse also weakens passwords, and allows the compromise
   of one account to enable the compromise of others. Password reuse
   nonetheless remains common.

   c. Password managers tackle these problems by storing several unique
   complex passwords in one encrypted database under a single memorable
   password.

   Cite:
   http://xkcd.com/936
   and accompanying links on the explainxkcd page:
   http://www.explainxkcd.com/wiki/index.php/936:_Password_Strength

   "If you write an article about choosing passwords where password
   managers aren't mentioned even once, you're not helping anyone."
   https://diogomonica.com/posts/password-security-why-the-horse-
           battery-staple-is-not-correct/

   "Users should not be choosing passwords."
   https://www.techdirt.com/articles/20100621/0934019896/dailydirt-how-
           many-passwords-do-you-know.shtml

   https://arstechnica.com/security/2014/04/stanfords-password-policy-
          shuns-one-size-fits-all-security/

   d. People are bad at generating unique, complex passwords, especially
   when asked to memorize same for many sites online.

   e. Users rarely change passwords if not required to do so.

   f. Password constraints limit entropy and are often not transparent,
   leading to frustrating user experiences when passwords are rejected
   for containing forbidden characters or failing to contain required
   characters, even when a proposed password is high in entropy.

1.2. Password Manager Security and Usability

   PMs can improve password security.

   a. PMs aid in the generation of passwords. Although the generation
   of highly secure pseudo random strings remains an area of active
   study, machines currently outperform humans at this task by almost
   any measure.

   cite:
   What Does Randomness Look Like? WIRED
   https://www.wired.com/2012/12/what-does-randomness-look-like/

   b. PMs can not only generate, but also serve as a "memory" for
   complex passwords.

   c. PMs generate and store unique passwords for each site, so the
   compromise of any one password does not necessarily provide useful
   information about passwords on other sites.

   d. Usability remains a hurdle to greater PM adoption.

   cite:
   http://www.npr.org/blogs/alltechconsidered/2014/11/03/361137779/lazy-
          about-your-online-passwords-take-control-with-these-new-tips
"Now, I'm not going to make the picture rosier than it is. 1Password is
not the easiest software to use. Even more annoyingly, if you currently
have weak passwords, you need to change those to something very
difficult to guess, then store that login in the software. Doing this
over and over is quick, but a hassle. For my 15 key sites, it took 22
minutes of concerted effort to complete. For other semi-important sites,
I'm just dealing with them as I go. I add a couple a day, at most."

   This password establishment protocol would improve the usability of
   PMs.

2. Specification of PM-PWD-NEG

   The establishment of a password on an online account provider (OAP)
   requires communication of password requirements and restrictions,
   a password to be securely transmitted, and a confirmation that the
   password was correctly set.

   Additional security considerations require that the password be
   communicated only in an encrypted channel, that responses from the
   OAP avoid leaking information about existing accounts or passwords,
   and that the exchange be resistant to replay attacks. Note that these
   considerations also apply to current password establishment
   procedures.

             PM                                               OAP
          --------                                          --------

           PM Hello and Authorization
           [username + existing password]
                                   -------->

                          OAP Password Requirements and Restrictions
                                   <--------

           Password Request
           [proposed new password]
                                   -------->

                                                    Success/Failure
                                   <--------

Note:

   Unless otherwise noted, the decimal numbers appearing in packet-
   format diagrams represent the length of the corresponding field, in
   octets.  Where a given octet must take on a specific value, the
   syntax X'hhhh hhhh' is used to denote the value of the octet in that
   field. When the word 'Variable' is used, it indicates that the
   corresponding field has a variable length defined either by an
   associated (one or two octet) length field, or by a data type field.


2.1. PM Hello and Authorization

   Transmission of a username and password has been handled before. (See
   RFC 1929 et. al.). Similar conventions are followed here.

           +-----+------+-------------+------+-------------+
           | VER | ULEN | USERNAME    | PLEN | PASSWORD    |
           +-----+------+-------------+------+-------------+
           | 1   |  1   | 1 to 255    |  1   | 1 to 255    |
           +-----+------+-------------+------+-------------+

   The VER field contains the current version of the protocol,
   which is currently X'0000 0001'. The ULEN field contains the length
   of the USERNAME field that follows. The USERNAME field contains the
   username. The PLEN field contains the length of the PASSWORD field
   that follows. The PASSWORD field contains the password associated
   with the given USERNAME.

   The server verifies the supplied UNAME and PASSWD, and if the
   information conforms to an existing account, replies with password
   requirements as indicated in the following section.

2.2. OAP Password Requirements

           +-------------------------+--------------------------------+
           | Allowed Character Sets  | FLEN | Forbidden Characters    |
           +-------------------------+------+-------------------------+
           |           2             |  1   |   0 To 255              |
           +-------------------------+------+-------------------------+
           |     Min Length          |     Max Length                 |
           +-------------------------+--------------------------------+
           |           1             |          1                     |
           +-------------------------+--------------------------------+

2.2.1. Allowed Character Sets

   The two octet field specifies sets of characters allowed for
   inclusion in a password by means of bit flags, using the following
   fields:

   0. ASCII lowercase
   1. ASCII uppercase
   2. Digits [0-9]
   3. All ASCII
   4. Space
   5. Basic special characters (US keyboard layout number row) !@#$%^&*()
   6. Brackets ()[]{}<>
   7. Punctuation ,.?'";:`~-
   8. Math -+*/=^.
   9. Bars /\|_-
   10. High ANSI
   11. All UTF-8
   12-15. Reserved.

   The selection of categories is intended primarily to allow OAPs to
   specify allowed passwords as easily as possible.

   Note that some of these categories overlap. The union of all flagged
   categories should be permitted. X'0000 1001' (All ASCII + ASCII
   lowercase), X'0000 1010' (All ASCII + ASCII uppercase), and
   X'0000 1000' (All ASCII) result in identical specifications.

   Comments are welcome on more useful categories here.

   No provision is provided for OAPs whose password systems fail to
   distinguish between upper and lower cases, because this can encourage
   a false sense of additional security.

2.2.2. FLEN

   This specifies the length of the Forbidden Characters field.

2.2.3. Forbidden Characters

   Forbidden characters are listed in this field using UTF-8 encoding.

   Comments are encouraged on whether or not this field is sufficient,
   or if other encoding schemes should be supported, or if a certain
   order should be recommended or required.

2.2.4. Min Length / Max Length

   The minimum and maximum permitted lengths of the password in
   bytes.

   Comments encouraged on whether or not this field should indicate
   length in characters, or length in bytes.

   Password lengths are most commonly referred to in terms of character
   lengths, despite protocol preference for bytes. Byte restrictions may
   require additional calculations by the PM for certain UTF-8
   passwords, but character-based limits may introduce complexities for
   OAP memory allocation.

   Byte length makes the rest of the protocol easier to standardize, so
   that is currently used, with the suspicion that character counts
   would be more useful.

2.3. Password Request

           +------+-------------+
           | PLEN | PASSWORD    |
           +------+-------------+
           |  1   | 1 to 255    |
           +------+-------------+

   The PLEN field contains the length of the PASSWORD field that
   follows. The PASSWORD field contains the requested new password.

   Comments encouraged on whether it would be helpful to restate
   the associated username. It is currently assumed that repeating the
   username would be redundant, and might even allow confusing a
   poorly configured OAP into changing an account without authorization.

2.4. Success/Failure

           +---------+
           | SUCCESS |
           +---------+
           |    1    |
           +---------+

   Success indicated by X'0000 0000'. All other results indicate failure.

   Comments encouraged on what specific failure codes might be useful
   without leaking information. (ie, there will be no failure code for
   "username not found". A failure code for insufficient length or use
   of forbidden character might be helpful for troubleshooting.)

3. Special Issues for Discussion:

3.1. Should PMs be allowed to set up new accounts?

   Current assumption is no, as automated account creation is disfavored
   online. OAPs often need to throttle account creation to prevent
   abuse, so an automated solution here would likely be frowned upon.

3.2. Should the PM be allowed to bypass the hello?

   Current assumption is no.

   The protocol could be simplified by having the initial communication
   consist of an authorization and new password request [username + old
   password + new password]. The OAP would simply reply with success or
   failure.

   The PM could store password requirements, requesting them only if
   needed, or verifying for changes on failure.

   However, a PM that never or rarely verifies requirements would never
   or rarely detect when an OAP increased security by expanding the
   domain of allowed passwords. Lag in the full adoption of OAP security
   improvements, though it would be rare, is judged a more significant
   risk than the additional overhead of two small packets for this
   infrequent communication.

3.3. Should PMs be required to authorize in hello?

   Current assumption is yes.

   Password requirements for OAPs should be publicly available, to allow
   new users and security researchers to evaluate the security of
   existing OAP password systems before account creation. But this
   information can be provided to humans in a separate channel.

   Requiring initial authorization limits opportunities for mischief,
   such as use of this protocol in denial of service attacks.

   OAP should abort the protocol on failed authentication for this to be
   effective.

   Like any authentication step, this allows an attacker to confirm the
   existence of a username password pair, and allows an opportunity for
   password guessing.

   For this reason, the protocol should be throttled by the OAP.
   Throttling specifics are considered out of scope here, given the
   many unique features of OAPs, but comments are welcomed if there is
   an appropriate way to address this in more detail.

3.3.1. Should authentication fail silently?

   Undecided.

   Silent failure would allow the OAP to quickly drop unauthorized
   requests, but risks encouraging well intentioned but misconfigured
   PMs to bash an incorrect username+password pair against the OAP
   while assuming a network error.

3.4. How should encryption requirements be detailed?

   To ensure confidentiality, passwords MUST NOT be transmitted in
   plaintext. This protocol includes the communication of passwords, but
   it is beyond the scope of this protocol to specify underlying
   encryption mechanisms required.

   Comments encouraged on current best practices for binding the RFC of
   a protocol to lower layer encrypted channels.

3.5. Password Length

   Provisions for very long (up to 65535 Byte) passwords were briefly
   considered and fairly promptly rejected.

   A protocol should specify maximum field lengths to prevent overflows.
   Maximum lengths for passwords, however, are generally discouraged.

   This apparent contradiction can be easily resolved.

   When security researchers criticize maximum password lengths, it is
   typically a criticism of OAPs that sharply limit passwords to very
   small lengths. Six or ten character limits on passwords are not
   unheard of, and these lengths are not only easily cracked, but
   usually taken as an indication of other security problems (ie, that
   passwords are stored by the OAP in plaintext).

   Best practices in hashing passwords for storage should prevent the
   OAP from caring too much about password lengths.

   OAPs may reasonably require that authentication will not consume
   terabytes of bandwidth or significant resources for hashing when such
   resources are not providing any additional meaningful security.
   Users may only reasonably require password lengths long enough to
   resist feasible attacks.

   There is a wide field of possible password lengths that accomodate
   both considerations. A 255 Byte password would be impervious to
   cracking by a universe-sized computer before the heat-death of the
   universe. Such a password would also be significantly stronger than
   underlying encryption, making the password no longer the primary
   vector of attack.

   The current protocol assumes a maximum length of 255 bytes for any
   username or password field, a value which is currently assumed to
   err well on the side of caution and considered aggressively future
   proofed while conveniently allowing a one byte field to specify its
   exact length. Comments are encouraged if another value would be
   sufficient or preferable. Please note especially any OAPs that allow
   incredibly long usernames that would be strained by this restriction.

3.6. Password Requirements Specification

   Should the protocol develop a password requirements specification
   mini-language? Should the protocol allow regular expressions to
   describe which passwords are acceptable and unacceptable?

   Current form proposed for simplicity. Regular expressions or the
   development of a novel mini-language here would needlessly
   complicate this task. Comments on feasibility of using regular
   expressions or some specialized mini-language highly encouraged.

3.7. Complexity Requirements

   Some OAPs require passwords to conform to certain complexity
   requirements. These requirements are varied and specific. Some
   include: "must contain at least one character from at least x
   different character sets", "must not contain a series of
   incremental digits", or "must not contain common dictionary words"
   (using a dictionary that will never be provided).

   A good PM will automatically generate complex passwords, but may
   occasionally generate passwords violating some arbitrary complexity
   restriction.

   Such requirements are difficult or impossible to represent in a
   simple protocol field because there is no clear limit on what rules
   could be imposed on any given system.

   Therefore, it is probably preferable to simply allow such passwords
   to be rejected, and have the PM try again, rather than attempting to
   communicate complexity requirements in this protocol. Ideal best
   practices would discourage complexity requirements, or at least
   suspend such requirements for interactions with PMs.

   TODO: ref, "Password complexity rules more annoying, less effective
   than lengthy ones", Casey Johnston, Ars Technica, June 28, 2013,
   http://arstechnica.com/security/2013/06/password-complexity-rules-
   more-annoying-less-effective-than-length-ones/
   (track down underlying 2011 study referenced there)

4. Acknowledgments

   TBD

5. Normative References

6. Informative References

Cracking 160 character password unlikely before heat death of universe
with universe sized computer:
http://forums.xkcd.com/viewtopic.php?f=12&t=74016

7. Security Considerations

TODO: TLS (or any future supplanting protocol) as a hard requirement for
PEP communications, see RFC 5246.

TODO: see RFC 3552

8. IANA Considerations

TODO: see RFC 2434. "No IANA Considerations" maybe?

TODO: RFC 793 for inspiration.

Appendix A.

Authors' Addresses

TBD

   See also:
ftp://ftp.rfc-editor.org/in-notes/rfc-editor/tutorial63.pdf
http://www.ietf.org/ID-Checklist.html
http://www.ietf.org/ietf/1id-guidelines.txt
RFC 2629 on writing I-Ds and RFCs in XML.
www.rfc-editor.org/howtopub.html
ftp.rfc-editor.org/in-notes/rfceditor/instructions2authors.txt (dead?)
rfc-editor@rfc-editor.org