--- /dev/null
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires: 11 January 2001 11 July 2000
+
+
+ LDAP Authentication Password Attribute
+ <draft-zeilenga-ldap-authpasswd-03.txt>
+
+
+
+1. Status of this Memo
+
+ This document is an Internet-Draft and is in full conformance with all
+ provisions of Section 10 of RFC2026.
+
+ This document is intended to be, after appropriate review and
+ revision, submitted to the RFC Editor as a Standard Track document.
+ Distribution of this memo is unlimited. Technical discussion of this
+ document will take place on the IETF LDAP Extension Working Group
+ mailing list <ietf-ldapext@netscape.com>. Please send editorial
+ comments directly to the author <Kurt@OpenLDAP.org>.
+
+ 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 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.''
+
+ 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.
+
+ Copyright 2000, The Internet Society. All Rights Reserved.
+
+ Please see the Copyright section near the end of this document for
+ more information.
+
+
+2. Abstract
+
+ This document describes schema for storing information in support of
+ user/password authentication in a LDAP [RFC2251] directory. The
+ document defines the authPassword attribute type and related schema.
+ The attribute type is used to store values derived from the user's
+ password(s) (commonly using cryptographic strength one-way hash).
+ authPassword is intended to used instead of clear text password
+
+
+
+Zeilenga [Page 1]
+\f
+INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
+
+
+ storage mechanisms such as userPassword [RFC2256]. The values of
+ authPassword may be used to support both LDAP "simple" and SASL
+ [RFC2222] password authentication mechanisms [RFC2829].
+
+ The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
+ NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in
+ this document are to be interpreted as described in RFC 2119
+ [RFC2119].
+
+
+3. Background and Intended Use
+
+ The userPassword attribute type [RFC 2256] is intended be used to used
+ to support the LDAP [RFC2251] "simple" bind operation. However,
+ values of userPassword must be clear text passwords. It is often
+ desirable to store values derived from the user's password(s) instead
+ of actual passwords.
+
+ The authPassword attribute type is intended to be used to store
+ information used to implement password based authentication. The
+ attribute type may be used by LDAP servers to implement user/password
+ authentication operations [RFC2829] such "simple" and SASL [RFC2222] /
+ DIGEST-MD5 [RFC2831].
+
+ The attribute type supports multiple storage schemes. A matching rule
+ is provided for use with extensible search filters to allow clients to
+ assert that a clear text password "matches" one of the attribute's
+ values. Storage schemes often use of cryptographic strength one-way
+ hashing.
+
+ This attribute may be used in conjunction with server side password
+ generation mechanisms (such as [PW-EXOP]).
+
+ Access to this attribute may governed by administrative controls such
+ as those which implement password change policies.
+
+
+4. Schema Definitions
+
+ The following schema definitions are described in terms of LDAPv3
+ Attribute Syntax Definitions [RFC2252] with specific syntax detailed
+ using Augmented BNF [RFC2234].
+
+ Editor's Note: object identifiers (OIDs) will be assigned before this
+ document is published as an RFC.
+
+4.1. authPasswordSyntax
+
+
+
+
+Zeilenga [Page 2]
+\f
+INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
+
+
+ ( authPasswordSyntaxOID
+ DESC 'authentication password syntax' )
+
+ Values of this syntax are encoded according to the following BNF:
+
+ authPasswordValue = w scheme s [authInfo] s authValue w
+ scheme = <an IA5 string of uppercase letters, numbers,
+ and "-", "_", and "/">
+ authInfo = schemeSpecificValue
+ authValue = schemeSpecfiicValue
+ schemeSpecificValue = <an IA5 printable string
+ not containing "$" or " ">
+ s = w sep w
+ w = *sp
+ sep = "$" ; an IA5 dollar sign (36)
+ sp = " " ; an IA5 space (20)
+
+ where scheme describes the storage mechanism, authInfo and authValue
+ are a scheme specific. The authInfo field is often a base64 encoded
+ salt. The authValue field is often a base64 encoded value derived
+ from a user's password(s). Values of this attribute are case
+ sensitive.
+
+ This document describes a number of schemes, as well as requirements
+ for the scheme naming, in section 5.
+
+
+4.2. authPasswordMatch
+
+ ( authPasswordMatchOID
+ NAME 'authPasswordMatch'
+ DESC 'authentication password matching rule'
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
+
+ This matching rule allows a client to assert that a password matches
+ values of authPasswordSyntax using an extensibleMatch filter
+ component. Each value is matched per its scheme. The assertion is
+ TRUE if one or more attribute values matches the asserted value, FALSE
+ if all values do not matches, and Undefined otherwise.
+
+ Servers which support use of this matching rule SHOULD publish
+ appropriate matchingRuleUse values per [RFC2252], 4.4.
+
+ Transfer of authPasswordMatch assertion values is strongly discouraged
+ where the underlying transport service cannot guarantee
+ confidentiality and may result in disclosure of the values to
+ unauthorized parties.
+
+
+
+
+Zeilenga [Page 3]
+\f
+INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
+
+
+4.3. supportedAuthPasswordSchemes
+
+ ( supportedAuthPasswordSchemesOID
+ NAME 'supportedAuthPasswordSchemes'
+ DESC 'supported password storage schemes'
+ EQUALITY caseExactIA5Match
+ SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32}
+ USAGE dSAOperation )
+
+ The values of this attribute are names of supported authentication
+ password schemes which the server supports. The syntax of a scheme
+ name is described in section 4.1. This attribute may only be present
+ in the root DSE. If the server does not support any mechanisms this
+ attribute will not be present.
+
+
+4.4. authPassword
+
+ ( authPasswordOID NAME 'authPassword'
+ SYNTAX authPasswordSyntaxOID )
+
+ The values of this attribute are representative of the user's
+ password(s) and conform to the authPasswordSyntax described in 4.1.
+ The values of this attribute may be used for authentication purposes.
+
+ This attribute type is defined without any built-in matching rules.
+ The absence of an EQUALITY matching rules disallows modification of
+ individual values.
+
+ Transfer of authPassword values is strongly discouraged where the
+ underlying transport service cannot guarantee confidentiality and may
+ result in disclosure of the values to unauthorized parties.
+
+
+4.5. authPasswordObject
+
+ ( authPasswordObjectOID NAME 'authPasswordObject'
+ DESC 'authentication password mix in class'
+ MAY 'authPassword' AUXILIARY )
+
+ Entries of this object class may contain authPassword attribute types.
+
+
+5. Schemes
+
+ This section describes the "MD5", "SHA1", and "SASL/DIGEST-MD5".
+ Other schemes may be defined by other documents. Schemes starting
+ with string "SASL/" indicate association with a SASL mechanism.
+
+
+
+Zeilenga [Page 4]
+\f
+INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
+
+
+ Schemes which are not described by standard track documents SHOULD be
+ named with a leading "X-" or, if associated with a SASL mechanism,
+ "SASL/X-" to indicate they are a private or implementation specific
+ mechanism, or may be named using the dotted-decimal representation
+ [RFC2252] of an OID assigned to the mechanism.
+
+
+5.1. MD5 scheme
+
+ The MD5 [RFC1321] scheme name is "MD5".
+
+ The authValue is the base64 encoding of an MD5 digest of the
+ concatenation the user password and optional salt. The base64
+ encoding of the salt is provided in the authInfo field.
+ Implementations of this scheme must support salts up to 128-bit in
+ length. Use with a 64-bit or larger salt is RECOMMENDED.
+
+ Example:
+ Given a user "joe" who's password is "mary" and a salt of "salt",
+ the authInfo field would be the base64 encoding of "salt" and the
+ authValue field would be the base64 encoding of the MD5 digest of
+ "marysalt".
+
+ A match against an asserted password and an attribute value of this
+ scheme SHALL be true if and only if the MD5 digest of concatenation of
+ the asserted value and the salt is equal to the MD5 digest contained
+ in AuthValue. The match SHALL be undefined if the server is unable to
+ complete the equality test for any reason. Otherwise the match SHALL
+ be false.
+
+ Values of this scheme SHOULD only be used to implement simple
+ user/password authentication.
+
+ It is RECOMMENDED that values of this scheme be protected as if they
+ were clear text passwords.
+
+
+5.2. SHA1 scheme
+
+ The SHA1 [SHA1] scheme name is "SHA1".
+
+ The authValue is the base64 encoding of an SHA1 digest of the
+ concatenation the user password and the optional salt. The base64
+ encoding of the salt is provided in the authInfo field.
+ Implementations of this scheme must support salts up to 128-bit in
+ length. Use with a 64-bit or larger salt is RECOMMENDED.
+
+ Example:
+
+
+
+Zeilenga [Page 5]
+\f
+INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
+
+
+ Given a user "joe" who's password is "mary" and a salt of "salt",
+ the authInfo field would be the base64 encoding of "salt" and the
+ authValue field would be the base64 encoding of the SHA1 digest of
+ "marysalt".
+
+ A match against an asserted password and an attribute value of this
+ scheme SHALL be true if and only if the SHA1 digest of concatenation
+ of the asserted value and the salt is equal to the SHA1 digest
+ contained in AuthValue. The match SHALL be undefined if the server is
+ unable to complete the equality test for any reason. Otherwise the
+ match SHALL be false.
+
+ Values of this scheme SHOULD only be used to implement simple
+ user/password authentication.
+
+ It is RECOMMENDED that values of this scheme be protected as if they
+ were clear text passwords.
+
+
+5.3. DIGEST-MD5 scheme
+
+ The DIGEST-MD5 scheme name is "SASL/DIGEST-MD5".
+
+ The authValue is the base64 encoding of
+ H( { username-value, ":", realm-value, ":", passwd } )
+
+ and authInfo is the base64 encoding of
+ { username-value, ":", realm-value }
+
+ as defined by RFC2831.
+
+ Example:
+ Given a user "joe" within the realm "localhost" who's password is
+ "mary", the info field would be the base64 encoding of
+ "joe:localhost" and the authValue field would be the base64 encoding
+ of the MD5 digest of "joe:localhost:mary".
+
+ Values of this scheme SHOULD only be used to implement the
+ SASL/DIGEST-MD5 as described by the Authentication Methods for LDAP
+ [RFC2829]. A simple password assertion against a value of this scheme
+ SHALL be considered undefined.
+
+ Values of this scheme MUST be protected as if it the values were clear
+ text passwords per reasons detailed in DIGEST-MD5, Section 3.9,
+ "Storing Passwords."
+
+
+6. Implementation Issues
+
+
+
+Zeilenga [Page 6]
+\f
+INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
+
+
+ For implementations of this specification:
+
+ Servers MAY restrict which schemes are used in conjunction with a
+ particular authentication process but SHOULD use all values of
+ selected schemes. If the asserted password matches any of the
+ stored values, the asserted password SHOULD be considered valid.
+ Servers MAY use other authentication storage mechanisms, such as
+ userPassword or an external password store, in conjunction with
+ authPassword to support the authentication process.
+
+ Servers that support simple bind MUST support the MD5 scheme and
+ SHOULD support the SHA1 scheme.
+
+ Servers SHOULD not publish values of authPassword nor allow
+ operations which expose authPassword or AuthPasswordMatch values to
+ unless confidentiality protection is in place.
+
+ Clients SHOULD not initiate operations which provide or request
+ values of authPassword or make authPasswordMatch assertions unless
+ confidentiality protection is in place.
+
+ Clients SHOULD not assume that a successful AuthPasswordMatch,
+ whether by compare or search, is sufficient to gain directory
+ access. The bind operation MUST be used to authentication to the
+ directory.
+
+
+7. Security Considerations
+
+ This document describes how authentication information may be stored
+ in a directory. Authentication information must be adequately
+ protected as unintended disclosure will allow attackers to gain
+ immediate access to the directory as described by [RFC2829].
+
+ Values of authPassword SHOULD be protected as if they were clear text
+ passwords. When values are transferred, privacy protections, such as
+ IPSEC or TLS, SHOULD be in place.
+
+ Clients SHOULD use strong authentication mechanisms [RFC2829].
+
+ AuthPasswordMatch matching rule allows applications to test the
+ validity of a user password and, hence, may be used to mount a
+ dictionary attack. Servers SHOULD take appropriate measures to
+ protect the directory from such attacks.
+
+ Some password schemes may require CPU intensive operations. Servers
+ SHOULD take appropriate measures to protect against Denial of Service
+ attacks.
+
+
+
+Zeilenga [Page 7]
+\f
+INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
+
+
+ AuthPassword does not restrict an authentication identity to a single
+ password. An attacker who gains write access to this attribute may
+ store additional values without disabling the user's true password(s).
+ Use of policy aware clients and servers is RECOMMENDED.
+
+ The level of protection offered against various attacks differ from
+ scheme to scheme. It is RECOMMENDED that servers support scheme
+ selection as a configuration item. This allows for a scheme to be
+ easily disabled if a significant security flaw is discovered.
+
+
+8. Copyright
+
+ Copyright 2000, The Internet Society. All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published and
+ distributed, in whole or in part, without restriction of any kind,
+ provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be followed,
+ or as required to translate it into languages other than English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
+ ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
+ INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
+ INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
+ WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+
+9. Acknowledgment
+
+ This document borrows from a number of IETF documents and is based
+ upon input from the IETF LDAPext working group.
+
+
+10. Bibliography
+
+ [RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,
+
+
+
+Zeilenga [Page 8]
+\f
+INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
+
+
+ April 1992
+
+ [RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
+ Requirement Levels", RFC 2119, March 1997.
+
+ [RFC2222] J. Myers, "Simple Authentication and Security Layer (SASL)",
+ RFC 2222, October 1997.
+
+ [RFC2234] D. Crocker (editor), P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
+ Directory Access Protocol (v3): Attribute Syntax
+ Definitions", RFC 2252, December 1997.
+
+ [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
+ with LDAPv3", RFC 2256, December 1997.
+
+ [RFC2307] L. Howard, "An Approach for Using LDAP as a Network
+ Information Service", RFC 2307, March 1998.
+
+ [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,
+ "Authentication Methods for LDAP", RFC 2829, June 2000.
+
+ [RFC2831] P. Leach, C. Newman, "Using Digest Authentication as a SASL
+ Mechanism", RFC 2831, June 2000.
+
+ [PW-EXOP] K. Zeilenga, "LDAP Password Modify Extended Operation"
+ draft-zeilenga-ldap-passwd-exop-xx.txt, a work in progress.
+
+ [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
+
+
+11. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+
+
+
+
+
+
+
+
+Zeilenga [Page 9]
+\f
projects / openldap / commitdiff