[Date Prev][Date Next] [Chronological] [Thread] [Top]

proposed standard for password syntaxes

Attached is a proposed standard for password syntaxes.  It follows what is commonly being used.  We need the definition solidified so we can move forward with it.

Pat Felsted
Novell, Inc.



Individual Submission to LDAPEXT WG                          P. Felsted
Internet Draft                                             Novell, Inc.
Document: draft-felsted-ldap-userpassword-00               October 1999
Category: Standards Track


             The userPassword Attribute and Syntax Defined


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026 [1].

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups. Note that
   other groups may also distribute working documents as Internet
   Drafts. Internet-Drafts are draft documents valid for a maximum of
   six months and may be updated, replaced, or made obsolete 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."
   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

1. Abstract

   The purpose of this document is to standardize the definitions of
   the userPassword attribute and the userPassword syntax by extending
   the [RFC2256] definition of this syntax and specifying a
   userPassword attribute description with options for representing
   various encryption schemes.  This is needed to allow different LDAP
   clients and servers to have a standard, comprehensive mechanism for
   modifying, exporting and importing changes to the userPassword
   attribute.

2. Conventions used in this document

   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 [RFC2119].

3. Encodings

   This document describes encodings used in an Internet protocol.

   This document builds upon [RFC2252], [RFC2256] and their
   predecessors.  Implementers are strongly encouraged to become
   familiar with those documents before reading this.




Felsted                                                              1

            The userPassword Attribute and Syntax Defined  Oct., 1999

   The definitions in this document are represented as strings in BNF.
   The intention is that the string representations are used in normal
   transmissions of attributes using these definitions.

4. User Password syntax Encoding

   The user password syntax as defined by [RFC2256] section 5.36 is
   stored as an unencrypted Octet String producing security concerns.
   Because of these security concerns, section 5.3 of [RFC2307] was
   written.  Many applications have implemented the userPassword syntax
   proposed by [RFC2307] and for backward compatibility this needs to
   be documented.  To support this, attributes using the userPassword
   syntax SHALL be represented by the following BNF:

      passwordvalue       = schemeprefix encryptedpassword /
                              Octet String
      schemeprefix        = "{" scheme "}"
      scheme              = "crypt" / "md5" / "sha" / altscheme
      altscheme           = "x-" keystring
      encryptedpassword   = encrypted password

   The encrypted password contains a clear text key hashed using the
   altscheme.  Below is an example of a userPassword attribute:

      userPassword: {crypt}X5/DBrWPOQQaI

   Server implementations MAY support the userPassword syntax for
   backward compatibility, particularly with LDAP v2 clients. The
   future use of the userPassword syntax by clients is strongly
   discouraged.  Going forward, the syntax that SHALL be used is Octet
   String as previously specified in [RFC2252].  The following section
   defines a new userPassword attribute definition using attribute
   descriptions to accomplish the same effect as the userPassword
   syntax.

5. User Password Attribute Encoding

   The standard proposed here uses [RFC2251] attribute descriptions to
   represent hashed passwords of various formats. This attribute MUST
   NOT be used with LDAP v2.

      attributedescription    = attributename / attributename sep
                                   attributeoption
      attributename           = "userPassword"
      sep                     = ";"
      attributeoption         = schemeclass "-" scheme
      schemeclass             = "hash" / altschemeclass
      scheme                  = "crypt" / "md5" / "sha" / altscheme
      altschemeclass          = "x-" keystring
      altscheme               = keystring

   Below is an example of a userPassword attribute, represented with an
   LDAP v3 attribute type description:


Felsted                  ldapext - April 2000                        2

            The userPassword Attribute and Syntax Defined  Oct., 1999

      userPassword;hash-crypt: X5/DBrWPOQQaI

   Note that it is improper to store a password encoded with the
   userPassword syntax in the userPassword attribute even though the
   octetString syntax would support such values.   For example,

      userPassword;hash-crypt: {crypt}X5/DBrWPOQQaI

   is an invalid value for the userPassword attribute.  Implementations
   MUST NOT allow values of this form to be represented in the
   userPassword attribute.

6. Security Considerations

   Although hashing a password and storing the hash in clear text is
   better than not hashing it and storing it in clear text, this is not
   a secure mechanism.  With enough computing power most of these
   hashes can be broken in a few days.

7. References

   [LDAPV3]
      M. Wahl, S. Kille and T. Howes, "Lightweight Directory Access
      Protocol (v3)", Internet Standard, December, 1997. Available as
      RFC2251.

   [RFC2252]
      M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directoyr
      Access Protocol (v3): Attribute Syntax Definitions", Internet
      Standard, December, 1997. Available as RFC2252.

   [RFC2119]
      S. Bradner, "Key Words for use in RFCs to Indicate Requirement
      Levels", Internet Standard, March, 1997. Available as RFC2119.

   [RFC2252]
      M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory
      Access Protocol (v3): Attribute Syntax Definitions", Internet
      Standard, December, 1997. Available as RFC2252.

   [RFC2253]
      M. Wahl, S. Kille, T. Howes, "Lightweight Directory Access
      Protocol (v3): UTF-8 String Representation of Distinguished
      Names", Internet Standard, December, 1997. Available as RFC2253.

   [RFC2307]
      L. Howard, "An Approach for Using LDAP as a Network Information
      Service", Internet Standard, March, 1998. Available as RFC2307.

8. Authors' Addresses

   Pat Felsted
   Novell, Inc.
   122 East 1700 South

Felsted                  ldapext - April 2000                        3

            The userPassword Attribute and Syntax Defined  Oct., 1999

   Provo, UT 84606
   USA
   +1 801 861 2646

Acknowledgements

      The author would like to thank the generous input and review by
      individuals at Novell including but not limited to Jim
      Sermersheim, Roger Harrison, John Mitchner, Hal Henderson and
      Blaine Southam.  And of course Luke Howard who basically proposed
      this in [RFC2307].












































Felsted                  ldapext - April 2000                        4