From: Kurt Zeilenga Date: Wed, 19 Jul 2000 01:32:20 +0000 (+0000) Subject: Add rev 3 X-Git-Tag: LDBM_PRE_GIANT_RWLOCK~2415 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=836d089e7483ea25fd3ca224c12079a6bd9797ac;p=openldap Add rev 3 --- diff --git a/doc/drafts/draft-zeilenga-ldap-authpasswd-xx.txt b/doc/drafts/draft-zeilenga-ldap-authpasswd-xx.txt new file mode 100644 index 0000000000..a4ae8e5592 --- /dev/null +++ b/doc/drafts/draft-zeilenga-ldap-authpasswd-xx.txt @@ -0,0 +1,501 @@ +INTERNET-DRAFT Kurt D. Zeilenga +Intended Category: Standard Track OpenLDAP Foundation +Expires: 11 January 2001 11 July 2000 + + + LDAP Authentication Password Attribute + + + + +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 . Please send editorial + comments directly to the author . + + 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] + +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] + +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 = + authInfo = schemeSpecificValue + authValue = schemeSpecfiicValue + schemeSpecificValue = + 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] + +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] + +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] + +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] + +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] + +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] + +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 + + + + + + + + + + + +Zeilenga [Page 9] +