[http-auth] password security and entropy - BCP needed

[Jonathan Stoke <[e-mail]>]

Internet-Draft                                                  J. STOKE
Request for Comments: nnnn                                    March 2013
Intended Status: Proposed Standard

                 BCP for Password-based Authentication
File Name:  draft-ietf-httpauth-stoke-password-policy-00.txt
Expiration Date:  January 9, 2014
Abstract
   There is no BCP for password-based authentication on the Internet.
   This form of authentication is common and prevalent. A BCP
   statement is long overdue, and it will require a paradigm shift on
   the part of the IETF to accomplish the goal. The first necessary
   step will be to arrive at a consensus that the goal must be
   accomplished and that the proper venue is the IETF.
Status of this Memo
   This document specifies an Internet Best Current Practices for
   the Internet Community, and requests discussion and suggestions
   for improvements.  Distribution of this memo is unlimited.

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79. Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF). Note that
   other groups may also distribute working documents as
   Internet-Drafts. The list of current Internet-Drafts is at
   http://datatracker.ietf.org/drafts/current.
   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time. It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."
Copyright Notice
   Copyright (c) 2013 IETF Trust and the persons identified as the
   document authors. All rights reserved.
   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document. Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.

STOKE                     Internet-Draft                        [page 1]

RFC nnnn         BCP for Password-based Authentication        March 2013
1. Definitions
   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119.
   "Username" means an ASCII string unique to one individual entity per
   realm.

   "Password" means an ASCII string associated to a username intended as
   a secret authentication factor known only to the authority performing
   credential-based authentication and the authorized user for whom it
   serves as a credential for authentication.
2. Introduction
   Historically Internet standards have generally been concerned with
   the technical specifications for hardware and software required for
   computer communication across interconnected networks. However,
   since the Internet itself is composed of networks operated by a great
   variety of organizations, with diverse goals and rules, good user
   service requires that the operators and administrators of the
   Internet follow some common guidelines for policies and operations.
   The lack of standards, policy, or guidelines regarding password-based
   authentication has resulted in widely varying and often incompatible
   or conflicting rule sets to which Internet users are expected to
   adapt.
   The limitations of human memory are well recognized as a
   result of many published studies. The rapid increase in the number
   of sites requiring passwords coupled with the admonitions to change
   passwords frequently and to use a unique password for every website
   now exceeds the design limitations of the average human user of the
   Internet. A BCP can help resolve this by providing certainty for
   Internet users, software designers, and site administrators.
3. Proposed Framework
   In order for an authentication portal to claim compliance with this
   RFC the following minimum requirements MUST be attained. Nothing in
   this RFC is intended to preclude any other schemes or policies.
   The permitted character set MUST include the numbers 0-9
   (ASCII 48-57 decimal), capital A-Z (ASCII 65-90 decimal), lower case
   a-z (ASCII 97-122 decimal), and the symbols on a standard keyboard
   appearing above the numbers 0-9, !@#$%^&*(), (ASCII 33, 64, 35, 36,
   37, 94, 38, 42, 40, 41 decimal).
   The prohibited character set MUST include the period (ASCII 46
   decimal) and the comma (ASCII 44 decimal).
STOKE                     Internet-Draft                        [page 2]

RFC nnnn         BCP for Password-based Authentication        March 2013
   The user MUST be permitted to select their username-password
   credential pair. By this it is meant that the username MUST be
   selected by the user and not assigned by the site administrator, or
   if a default for either the username and/or the password is assigned,
   then the user MUST have the option to modify either or both.
   The user MUST have the option to register a notification address,
   such as an email address or text-capable device, with the
   authentication portal administrator.
   The user MUST be permitted to update either the username, or the
   password, or both, at any time and all changes MUST be reported to
   the registered notification address.
   The user MUST NOT be required to update either the username, or the
   password, or both; except in the case when an initial, default
   username and/or password is assigned.
   The user MUST be afforded a mechanism by which to report a
   compromised account and such reports MUST be addressed in less than
   one business day.
   The user MUST have the option of a secure logon using https links
   secured by sites offering credentials signed by a recognized
   Certification Authority (CA) using the latest secure methods for
   accessing a web site (which at present is the latest version of TLS
   [RFC5246]).
   The user's credentials stored in a database MUST be adequately
   secured with encryption equivalent to or stronger than 128-bit AES
   encryption and strong access controls.
   The user's credentials MUST be protected against brute force attack
   by implementation of a failed login policy and that policy MUST NOT
   divulge information useful to an attacker (e.g. the message MUST NOT
   state "username does not exist").
   The user MUST be informed of the credential requirements, including
   minimum length, maximum length, and permitted character set.
   The user MUST be informed if access to the single account is granted
   to more than one credential pair, and MUST be informed whenever more
   than one credential pair is valid for access to the account.
   The user MUST be informed of any available forgotten password reset
   mechanisms, and MUST NOT be required to enable or configure a reset
   mechanism.

STOKE                     Internet-Draft                        [page 3]

RFC nnnn         BCP for Password-based Authentication        March 2013
4. Discussion
   The purpose of this RFC is to focus discussion on the issue of a lack
   of defining standards for password-based authentication on the
   Internet. No proposed solutions in this document are intended as
   standards for the Internet. Rather, it is hoped that a general
   consensus will emerge as to the appropriate policy, leading
   eventually to the adoption of a BCP.
   For instance, the discussion of what symbols from the ASCII character
   set will be part of the standard permitted symbols for use would
   consider security in determining if a period or a comma would be
   permitted. These characters are often used in scripting, and script
   injection attacks would be diminished if these characters were not
   permitted. On the other hand, if these characters were permitted, and
   Internet users were aware of this fact as part of a BCP, then the
   user would have a larger character set from which to create passwords
   thus significantly increasing security.
   Discussion will eventually need to take place for
   internationalization of a BCP document.
   To become a BCP, a consensus would need to emerge concerning such
   details as a minimum password length, a minimum encryption standard
   for protection of the credential database, and the failed logon
   lockout policy, to name just a few key decisions.

   Complex decisions, such as inclusion or exclusion of unprintable
   control characters (ASCII 0 through 31 and 127 decimal) and the
   nonprinting space character (ASCII 32 decimal) will require
   consideration and discussion.

   Definitions will need to be standardized, beginning with definitions
   for "username" and "password".
   This proposed framework resembles a statement of user rights and
   responsibilities. It digresses from the paradigm that users must be
   protected from themselves, and instead moves toward the paradigm that
   users shall be given adequate information to make and implement
   informed decisions.
   The crucial hurdle that must be overcome, however, is that of
   requiring a paradigm shift on the part of the IETF. The IETF has
   thus far avoided this difficult issue for reasons apparently based in
   tradition and history rather than logic and need.
5. Interest
   This RFC is being distributed to members of the Internet community in
   order to solicit their reactions to the proposals contained in it.
   While the issues discussed may not be directly relevant to the
   research problems of the Internet, they may be interesting to a
   number of researchers and implementers.

STOKE                     Internet-Draft                        [page 4]

RFC nnnn         BCP for Password-based Authentication        March 2013
6. Security Considerations
   The entire purpose and focus of this BCP is to foster and enhance a
   secure environment for internet users dependent upon credential-based
   authentication.
7. IANA Considerations
   IANA considerations are truly believed to be irrelevant to this
   document.
8. References
8.1.  Normative References

   [RFC3629]          Yergeau, F., "UTF-8, a transformation format of
                      ISO 10646", STD 63, RFC 3629, November 2003.
   [RFC2119]          Bradner, S., "Key words for use in RFCs to
                      Indicate Requirement Levels", BCP 14, RFC 2119,
                      March 1997.
   [RFC5246]          Dierks, T. and E. Rescorla, "The Transport Layer
                      Security (TLS) Protocol Version 1.2", RFC 5246,
                      August 2008.
8.2.  Informative References
   [ISO10646]         International Organization for Standardization,
                      "Information Technology -- Universal Multiple-
                      Octet Coded Character Set (UCS)", ISO/
                      IEC 10646:2003, December 2003.

   [US-ASCII]         American National Standards Institute, "Coded
                      Character Set -- 7-bit American Standard Code for
                      Information Interchange", ANSI X3.4-1968, 1968.
   [Unicode]          The Unicode Consortium, "The Unicode Standard,
                      Version 5.0", 2006. (Addison-Wesley, 2006.
                      ISBN 0-321-48091-0).

   [RFC2818]          Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.

   [RFC1704]          Haller, N. & R. Atkinson, "On Internet
                      Authentication", RFC 1704, October 1994.

   [FIPS197]          National Bureau of Standards, "Advanced Encryption
                      Standard", Federal Information Processing
                      Printing Office, Washington, DC, November 2001.
STOKE                     Internet-Draft                        [page 5]

RFC nnnn         BCP for Password-based Authentication        March
2013

Author's Address
jonathan stoke
4608 E. Baytree Court
Boise, ID  83716
Phone: [phone]
Email: [e-mail]
File Name:  draft-ietf-httpauth-stoke-password-policy-00.txt
Expiration Date:  January 9, 2014





















STOKE                     Internet-Draft                        [page 6]