SHARE
TWEET

Password Establishment Protocol

brownbat Jun 6th, 2015 15,338 Never
Not a member of Pastebin yet? Sign Up, it unlocks many cool features!
  1. Network Working Group                                   Thomas Brownback
  2. Request for Comments: xxxx                        Independent Researcher
  3. Category: Experimental                                        Month YYYY
  4.  
  5.                Password Negotiation for Password Managers
  6.  
  7. Abstract
  8.  
  9.    This document proposes a protocol that would enable a password
  10.    manager (PM) to register or change a password with online
  11.    services. The minimal user involvement would improve the usability of
  12.    PMs, a current hurdle in more widespread adoption. Increased use of
  13.    PMs would improve password management by reducing the frequency of
  14.    common, simple, reused, or rarely changed passwords online,
  15.    significant current vulnerabilities for the web.
  16.  
  17. Status of this Memo
  18.  
  19.    This document defines an Experimental Protocol for the Internet
  20.    community. Discussion and suggestions for improvement are requested.
  21.    Distribution of this memo is unlimited.
  22.  
  23. Copyright Notice
  24.  
  25.    This memo is public domain by declaration of the author.
  26.    
  27. Table of Contents
  28.  
  29.    TBD
  30.      
  31. 1.  Introduction
  32.  
  33.    Automated password negotiation between a password manager (PM) and an
  34.    online account provider (OAP) would allow users to rapidly establish
  35.    secure, unique passwords on many websites, improving password
  36.    security on the Internet.
  37.      
  38. 1.1. Password Security
  39.    
  40.    Password issues are a key source of insecurity on the Internet.
  41.    
  42.    a. Passwords must be complex to prevent attack. Passwords must also
  43.    be memorable to allow reuse. Complexity and memorability are at odds.
  44.    
  45.    b. Password reuse also weakens passwords, and allows the compromise
  46.    of one account to enable the compromise of others. Password reuse
  47.    nonetheless remains common.
  48.    
  49.    c. Password managers tackle these problems by storing several unique
  50.    complex passwords in one encrypted database under a single memorable
  51.    password.
  52.    
  53.    Cite:
  54.    http://xkcd.com/936
  55.    and accompanying links on the explainxkcd page:
  56.    http://www.explainxkcd.com/wiki/index.php/936:_Password_Strength
  57.    
  58.    "If you write an article about choosing passwords where password
  59.    managers aren't mentioned even once, you're not helping anyone."
  60.    https://diogomonica.com/posts/password-security-why-the-horse-
  61.            battery-staple-is-not-correct/
  62.    
  63.    "Users should not be choosing passwords."
  64.    https://www.techdirt.com/articles/20100621/0934019896/dailydirt-how-
  65.            many-passwords-do-you-know.shtml
  66.            
  67.    https://arstechnica.com/security/2014/04/stanfords-password-policy-
  68.           shuns-one-size-fits-all-security/
  69.      
  70.    d. People are bad at generating unique, complex passwords, especially
  71.    when asked to memorize same for many sites online.
  72.    
  73.    e. Users rarely change passwords if not required to do so.
  74.    
  75.    f. Password constraints limit entropy and are often not transparent,
  76.    leading to frustrating user experiences when passwords are rejected
  77.    for containing forbidden characters or failing to contain required
  78.    characters, even when a proposed password is high in entropy.
  79.        
  80. 1.2. Password Manager Security and Usability
  81.    
  82.    PMs can improve password security.
  83.    
  84.    a. PMs aid in the generation of passwords. Although the generation
  85.    of highly secure pseudo random strings remains an area of active
  86.    study, machines currently outperform humans at this task by almost
  87.    any measure.
  88.    
  89.    cite:
  90.    What Does Randomness Look Like? WIRED
  91.    https://www.wired.com/2012/12/what-does-randomness-look-like/
  92.  
  93.    b. PMs can not only generate, but also serve as a "memory" for
  94.    complex passwords.
  95.    
  96.    c. PMs generate and store unique passwords for each site, so the
  97.    compromise of any one password does not necessarily provide useful
  98.    information about passwords on other sites.
  99.  
  100.    d. Usability remains a hurdle to greater PM adoption.
  101.    
  102.    cite:
  103.    http://www.npr.org/blogs/alltechconsidered/2014/11/03/361137779/lazy-
  104.           about-your-online-passwords-take-control-with-these-new-tips
  105. "Now, I'm not going to make the picture rosier than it is. 1Password is
  106. not the easiest software to use. Even more annoyingly, if you currently
  107. have weak passwords, you need to change those to something very
  108. difficult to guess, then store that login in the software. Doing this
  109. over and over is quick, but a hassle. For my 15 key sites, it took 22
  110. minutes of concerted effort to complete. For other semi-important sites,
  111. I'm just dealing with them as I go. I add a couple a day, at most."
  112.    
  113.    This password establishment protocol would improve the usability of
  114.    PMs.
  115.    
  116. 2. Specification of PM-PWD-NEG
  117.    
  118.    The establishment of a password on an online account provider (OAP)
  119.    requires communication of password requirements and restrictions,
  120.    a password to be securely transmitted, and a confirmation that the
  121.    password was correctly set.
  122.    
  123.    Additional security considerations require that the password be
  124.    communicated only in an encrypted channel, that responses from the
  125.    OAP avoid leaking information about existing accounts or passwords,
  126.    and that the exchange be resistant to replay attacks. Note that these
  127.    considerations also apply to current password establishment
  128.    procedures.
  129.    
  130.              PM                                               OAP
  131.           --------                                          --------
  132.  
  133.            PM Hello and Authorization
  134.            [username + existing password]
  135.                                    -------->
  136.  
  137.                           OAP Password Requirements and Restrictions
  138.                                    <--------      
  139.  
  140.            Password Request
  141.            [proposed new password]
  142.                                    -------->
  143.  
  144.                                                     Success/Failure
  145.                                    <--------                      
  146.  
  147. Note:
  148.  
  149.    Unless otherwise noted, the decimal numbers appearing in packet-
  150.    format diagrams represent the length of the corresponding field, in
  151.    octets.  Where a given octet must take on a specific value, the
  152.    syntax X'hhhh hhhh' is used to denote the value of the octet in that
  153.    field. When the word 'Variable' is used, it indicates that the
  154.    corresponding field has a variable length defined either by an
  155.    associated (one or two octet) length field, or by a data type field.
  156.  
  157.  
  158. 2.1. PM Hello and Authorization
  159.  
  160.    Transmission of a username and password has been handled before. (See
  161.    RFC 1929 et. al.). Similar conventions are followed here.
  162.  
  163.            +-----+------+-------------+------+-------------+
  164.            | VER | ULEN | USERNAME    | PLEN | PASSWORD    |
  165.            +-----+------+-------------+------+-------------+
  166.            | 1   |  1   | 1 to 255    |  1   | 1 to 255    |
  167.            +-----+------+-------------+------+-------------+
  168.  
  169.    The VER field contains the current version of the protocol,
  170.    which is currently X'0000 0001'. The ULEN field contains the length
  171.    of the USERNAME field that follows. The USERNAME field contains the
  172.    username. The PLEN field contains the length of the PASSWORD field
  173.    that follows. The PASSWORD field contains the password associated
  174.    with the given USERNAME.
  175.  
  176.    The server verifies the supplied UNAME and PASSWD, and if the
  177.    information conforms to an existing account, replies with password
  178.    requirements as indicated in the following section.
  179.            
  180. 2.2. OAP Password Requirements
  181.  
  182.            +-------------------------+--------------------------------+
  183.            | Allowed Character Sets  | FLEN | Forbidden Characters    |
  184.            +-------------------------+------+-------------------------+
  185.            |           2             |  1   |   0 To 255              |
  186.            +-------------------------+------+-------------------------+
  187.            |     Min Length          |     Max Length                 |
  188.            +-------------------------+--------------------------------+
  189.            |           1             |          1                     |
  190.            +-------------------------+--------------------------------+
  191.  
  192. 2.2.1. Allowed Character Sets
  193.        
  194.    The two octet field specifies sets of characters allowed for
  195.    inclusion in a password by means of bit flags, using the following
  196.    fields:
  197.    
  198.    0. ASCII lowercase
  199.    1. ASCII uppercase
  200.    2. Digits [0-9]
  201.    3. All ASCII
  202.    4. Space
  203.    5. Basic special characters (US keyboard layout number row) !@#$%^&*()
  204.    6. Brackets ()[]{}<>
  205.    7. Punctuation ,.?'";:`~-
  206.    8. Math -+*/=^.
  207.    9. Bars /\|_-
  208.    10. High ANSI
  209.    11. All UTF-8
  210.    12-15. Reserved.
  211.    
  212.    The selection of categories is intended primarily to allow OAPs to
  213.    specify allowed passwords as easily as possible.
  214.  
  215.    Note that some of these categories overlap. The union of all flagged
  216.    categories should be permitted. X'0000 1001' (All ASCII + ASCII
  217.    lowercase), X'0000 1010' (All ASCII + ASCII uppercase), and
  218.    X'0000 1000' (All ASCII) result in identical specifications.
  219.    
  220.    Comments are welcome on more useful categories here.
  221.    
  222.    No provision is provided for OAPs whose password systems fail to
  223.    distinguish between upper and lower cases, because this can encourage
  224.    a false sense of additional security.
  225.    
  226. 2.2.2. FLEN
  227.  
  228.    This specifies the length of the Forbidden Characters field.
  229.    
  230. 2.2.3. Forbidden Characters
  231.  
  232.    Forbidden characters are listed in this field using UTF-8 encoding.
  233.    
  234.    Comments are encouraged on whether or not this field is sufficient,
  235.    or if other encoding schemes should be supported, or if a certain
  236.    order should be recommended or required.
  237.  
  238. 2.2.4. Min Length / Max Length
  239.  
  240.    The minimum and maximum permitted lengths of the password in
  241.    bytes.
  242.    
  243.    Comments encouraged on whether or not this field should indicate
  244.    length in characters, or length in bytes.
  245.    
  246.    Password lengths are most commonly referred to in terms of character
  247.    lengths, despite protocol preference for bytes. Byte restrictions may
  248.    require additional calculations by the PM for certain UTF-8
  249.    passwords, but character-based limits may introduce complexities for
  250.    OAP memory allocation.
  251.    
  252.    Byte length makes the rest of the protocol easier to standardize, so
  253.    that is currently used, with the suspicion that character counts
  254.    would be more useful.
  255.    
  256. 2.3. Password Request
  257.  
  258.            +------+-------------+
  259.            | PLEN | PASSWORD    |
  260.            +------+-------------+
  261.            |  1   | 1 to 255    |
  262.            +------+-------------+
  263.  
  264.    The PLEN field contains the length of the PASSWORD field that
  265.    follows. The PASSWORD field contains the requested new password.
  266.            
  267.    Comments encouraged on whether it would be helpful to restate
  268.    the associated username. It is currently assumed that repeating the
  269.    username would be redundant, and might even allow confusing a
  270.    poorly configured OAP into changing an account without authorization.
  271.            
  272. 2.4. Success/Failure
  273.  
  274.            +---------+
  275.            | SUCCESS |
  276.            +---------+
  277.            |    1    |
  278.            +---------+
  279.  
  280.    Success indicated by X'0000 0000'. All other results indicate failure.
  281.    
  282.    Comments encouraged on what specific failure codes might be useful
  283.    without leaking information. (ie, there will be no failure code for
  284.    "username not found". A failure code for insufficient length or use
  285.    of forbidden character might be helpful for troubleshooting.)
  286.    
  287. 3. Special Issues for Discussion:
  288.  
  289. 3.1. Should PMs be allowed to set up new accounts?
  290.  
  291.    Current assumption is no, as automated account creation is disfavored
  292.    online. OAPs often need to throttle account creation to prevent
  293.    abuse, so an automated solution here would likely be frowned upon.
  294.    
  295. 3.2. Should the PM be allowed to bypass the hello?
  296.  
  297.    Current assumption is no.
  298.    
  299.    The protocol could be simplified by having the initial communication
  300.    consist of an authorization and new password request [username + old
  301.    password + new password]. The OAP would simply reply with success or
  302.    failure.
  303.    
  304.    The PM could store password requirements, requesting them only if
  305.    needed, or verifying for changes on failure.
  306.    
  307.    However, a PM that never or rarely verifies requirements would never
  308.    or rarely detect when an OAP increased security by expanding the
  309.    domain of allowed passwords. Lag in the full adoption of OAP security
  310.    improvements, though it would be rare, is judged a more significant
  311.    risk than the additional overhead of two small packets for this
  312.    infrequent communication.
  313.  
  314. 3.3. Should PMs be required to authorize in hello?
  315.  
  316.    Current assumption is yes.
  317.    
  318.    Password requirements for OAPs should be publicly available, to allow
  319.    new users and security researchers to evaluate the security of
  320.    existing OAP password systems before account creation. But this
  321.    information can be provided to humans in a separate channel.
  322.    
  323.    Requiring initial authorization limits opportunities for mischief,
  324.    such as use of this protocol in denial of service attacks.
  325.    
  326.    OAP should abort the protocol on failed authentication for this to be
  327.    effective.
  328.  
  329.    Like any authentication step, this allows an attacker to confirm the
  330.    existence of a username password pair, and allows an opportunity for
  331.    password guessing.
  332.    
  333.    For this reason, the protocol should be throttled by the OAP.
  334.    Throttling specifics are considered out of scope here, given the
  335.    many unique features of OAPs, but comments are welcomed if there is
  336.    an appropriate way to address this in more detail.
  337.    
  338. 3.3.1. Should authentication fail silently?
  339.    
  340.    Undecided.
  341.    
  342.    Silent failure would allow the OAP to quickly drop unauthorized
  343.    requests, but risks encouraging well intentioned but misconfigured
  344.    PMs to bash an incorrect username+password pair against the OAP
  345.    while assuming a network error.
  346.    
  347. 3.4. How should encryption requirements be detailed?
  348.  
  349.    To ensure confidentiality, passwords MUST NOT be transmitted in
  350.    plaintext. This protocol includes the communication of passwords, but
  351.    it is beyond the scope of this protocol to specify underlying
  352.    encryption mechanisms required.
  353.    
  354.    Comments encouraged on current best practices for binding the RFC of
  355.    a protocol to lower layer encrypted channels.
  356.    
  357. 3.5. Password Length
  358.  
  359.    Provisions for very long (up to 65535 Byte) passwords were briefly
  360.    considered and fairly promptly rejected.
  361.    
  362.    A protocol should specify maximum field lengths to prevent overflows.
  363.    Maximum lengths for passwords, however, are generally discouraged.
  364.    
  365.    This apparent contradiction can be easily resolved.
  366.  
  367.    When security researchers criticize maximum password lengths, it is
  368.    typically a criticism of OAPs that sharply limit passwords to very
  369.    small lengths. Six or ten character limits on passwords are not
  370.    unheard of, and these lengths are not only easily cracked, but
  371.    usually taken as an indication of other security problems (ie, that
  372.    passwords are stored by the OAP in plaintext).
  373.    
  374.    Best practices in hashing passwords for storage should prevent the
  375.    OAP from caring too much about password lengths.
  376.    
  377.    OAPs may reasonably require that authentication will not consume
  378.    terabytes of bandwidth or significant resources for hashing when such
  379.    resources are not providing any additional meaningful security.
  380.    Users may only reasonably require password lengths long enough to
  381.    resist feasible attacks.
  382.    
  383.    There is a wide field of possible password lengths that accomodate
  384.    both considerations. A 255 Byte password would be impervious to
  385.    cracking by a universe-sized computer before the heat-death of the
  386.    universe. Such a password would also be significantly stronger than
  387.    underlying encryption, making the password no longer the primary
  388.    vector of attack.
  389.    
  390.    The current protocol assumes a maximum length of 255 bytes for any
  391.    username or password field, a value which is currently assumed to
  392.    err well on the side of caution and considered aggressively future
  393.    proofed while conveniently allowing a one byte field to specify its
  394.    exact length. Comments are encouraged if another value would be
  395.    sufficient or preferable. Please note especially any OAPs that allow
  396.    incredibly long usernames that would be strained by this restriction.
  397.    
  398. 3.6. Password Requirements Specification
  399.  
  400.    Should the protocol develop a password requirements specification
  401.    mini-language? Should the protocol allow regular expressions to
  402.    describe which passwords are acceptable and unacceptable?
  403.    
  404.    Current form proposed for simplicity. Regular expressions or the
  405.    development of a novel mini-language here would needlessly
  406.    complicate this task. Comments on feasibility of using regular
  407.    expressions or some specialized mini-language highly encouraged.
  408.    
  409. 3.7. Complexity Requirements
  410.  
  411.    Some OAPs require passwords to conform to certain complexity
  412.    requirements. These requirements are varied and specific. Some
  413.    include: "must contain at least one character from at least x
  414.    different character sets", "must not contain a series of
  415.    incremental digits", or "must not contain common dictionary words"
  416.    (using a dictionary that will never be provided).
  417.    
  418.    A good PM will automatically generate complex passwords, but may
  419.    occasionally generate passwords violating some arbitrary complexity
  420.    restriction.
  421.  
  422.    Such requirements are difficult or impossible to represent in a
  423.    simple protocol field because there is no clear limit on what rules
  424.    could be imposed on any given system.
  425.      
  426.    Therefore, it is probably preferable to simply allow such passwords
  427.    to be rejected, and have the PM try again, rather than attempting to
  428.    communicate complexity requirements in this protocol. Ideal best
  429.    practices would discourage complexity requirements, or at least
  430.    suspend such requirements for interactions with PMs.
  431.  
  432.    TODO: ref, "Password complexity rules more annoying, less effective
  433.    than lengthy ones", Casey Johnston, Ars Technica, June 28, 2013,
  434.    http://arstechnica.com/security/2013/06/password-complexity-rules-
  435.    more-annoying-less-effective-than-length-ones/
  436.    (track down underlying 2011 study referenced there)
  437.  
  438. 4. Acknowledgments
  439.  
  440.    TBD
  441.  
  442. 5. Normative References
  443.  
  444. 6. Informative References
  445.  
  446. Cracking 160 character password unlikely before heat death of universe
  447. with universe sized computer:
  448. http://forums.xkcd.com/viewtopic.php?f=12&t=74016
  449.  
  450. 7. Security Considerations
  451.  
  452. TODO: TLS (or any future supplanting protocol) as a hard requirement for
  453. PEP communications, see RFC 5246.
  454.  
  455. TODO: see RFC 3552
  456.  
  457. 8. IANA Considerations
  458.    
  459. TODO: see RFC 2434. "No IANA Considerations" maybe?
  460.    
  461. TODO: RFC 793 for inspiration.
  462.    
  463. Appendix A.
  464.  
  465. Authors' Addresses
  466.  
  467. TBD
  468.    
  469.    See also:
  470. ftp://ftp.rfc-editor.org/in-notes/rfc-editor/tutorial63.pdf
  471. http://www.ietf.org/ID-Checklist.html
  472. http://www.ietf.org/ietf/1id-guidelines.txt  
  473. RFC 2629 on writing I-Ds and RFCs in XML.
  474. www.rfc-editor.org/howtopub.html
  475. ftp.rfc-editor.org/in-notes/rfceditor/instructions2authors.txt (dead?)
  476. rfc-editor@rfc-editor.org
RAW Paste Data
We use cookies for various purposes including analytics. By continuing to use Pastebin, you agree to our use of cookies as described in the Cookies Policy. OK, I Understand
Not a member of Pastebin yet?
Sign Up, it unlocks many cool features!
 
Top