--- /dev/null
+INTERNET-DRAFT Kurt D. Zeilenga
+Intended Category: Standard Track OpenLDAP Foundation
+Expires: 13 December 2000 13 June 2000
+
+
+ LDAP Password Modify Extended Operation
+ <draft-zeilenga-ldap-passwd-exop-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
+
+ The integration of LDAP [RFC2251] and external authentication services
+ has introduced non-DN authentication identities and allowed for
+ non-directory storage of passwords. As such, mechanisms which update
+ the directory, such as Modify operation, cannot be used to change a
+ user's password. This document describes an LDAP extended operation
+ to allow allow modification of user passwords which is not dependent
+ upon the form of the authentication identity nor the password storage
+
+
+
+Zeilenga [Page 1]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-passwd-exop-03 13 June 2000
+
+
+ mechanism used.
+
+ 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 Intent of Use
+
+ Lightweight Directory Access Protocol (LDAP) [RFC2251] is designed to
+ support an number of authentication mechanisms including simple user
+ name/password pairs. Traditionally LDAP users where identified by the
+ Distinguished Name [RFC2253] of a directory entry and this entry
+ contained a userPassword [RFC2256] attribute containing one or more
+ passwords.
+
+ The protocol does not mandate that passwords associated with a user be
+ stored in the directory server. The server may use any attribute
+ suitable for password storage, such as userPassword or authPassword
+ [AuthPasswd], or use non-directory storage.
+
+ The integration of application neutral SASL [RFC2222] services which
+ support simple username/password mechanisms (such as DIGEST-MD5) has
+ introduced non-LDAP DN authentication identity forms and made storage
+ of passwords the responsibility of the SASL service provider.
+
+ LDAP update operations are designed to act upon attributes of an entry
+ within the directory. LDAP update operations cannot be used to modify
+ a user's password when the user is not represented by a DN, does not
+ have a entry, or when that password used by the server is not stored
+ as an attribute of an entry. An alternative mechanism are needed.
+
+ This document describes an LDAP Extended Operation intended to be
+ allow directory clients to update user passwords. The user may or may
+ not have be associated with a directory entry. The user may or may not
+ be represented as an LDAP DN. The user's password may or may not be
+ stored in the directory.
+
+ The operation SHOULD NOT be used without adequate security protection
+ as the operation affords no privacy or integrity protect itself. This
+ operation SHOULD NOT be used by "anonymous" clients.
+
+
+4. Password Modify Request and Response
+
+ The Password Modify operation is an LDAPv3 Extended Operation
+ [RFC2251, Section 4.12] and is identified by the OBJECT IDENTIFIER
+
+
+
+Zeilenga [Page 2]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-passwd-exop-03 13 June 2000
+
+
+ passwdModifyOID. This section details the syntax of the protocol
+ request and response.
+
+ passwdModifyOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.4203.666.6.1
+
+ [Editor's Note: this OID is temporary. A permanent OID
+ will be assigned to this object before this document is
+ progressed as an RFC.]
+
+ PasswdModifyRequestValue ::= SEQUENCE {
+ userIdentity [0] OCTET STRING OPTIONAL
+ oldPasswd [1] OCTET STRING OPTIONAL
+ newPasswd [2] OCTET STRING OPTIONAL }
+
+ PasswordModifyResponseValue ::= SEQUENCE {
+ genPasswd [0] OCTET STRING OPTIONAL }
+
+
+4.1. Password Modify Request
+
+ A Password Modify request is an ExtendedRequest with the requestName
+ field containing passwdModifyOID OID and optionally provides a
+ requestValue field. If the requestValue field is provided, it SHALL
+ contain a PasswdModifyRequestValue with one or more fields present.
+
+ The userIdentity field, if present, SHALL contain an octet string
+ representation of the user associated with the request. This string
+ may or may not be an LDAPDN [RFC2253]. If no userIdentity field is
+ present, the request acts up upon the password of the user currently
+ associated with the LDAP session.
+
+ The oldPasswd field, if present, SHALL contain the user's current
+ password.
+
+ The newPasswd field, if present, SHALL contain the desired password
+ for this user.
+
+
+4.2. Password Modify Response
+
+ A Password Modify response is an ExtendedResponse where the
+ responseName field is absent and the response field is optional. The
+ response field, if present, SHALL contain a PasswdModifyResponseValue
+ with genPasswd field present.
+
+ The genPasswd field, if present, SHALL contain a generated password
+ for the user.
+
+
+
+
+Zeilenga [Page 3]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-passwd-exop-03 13 June 2000
+
+
+ If an resultCode other than success (0) is indicated in the response,
+ the response field MUST be absent.
+
+
+5. Operation Requirements
+
+ Clients SHOULD NOT submit a Password Modification request without
+ ensuring adequate security safeguards are in place. Servers SHOULD
+ return a non-success resultCode if sufficient security protection are
+ not in place.
+
+ Servers SHOULD indicate their support for this extended operation by
+ providing PasswordModifyOID as a value of the supportedExtensions
+ attribute type in their root DSE. Clients SHOULD verify the server
+ implements this extended operation prior to attempting the operation
+ by asserting the supportedExtensions attribute contains a value of
+ PasswordModifyOID.
+
+ The server SHALL only return success upon successfully changing the
+ user's password. The server SHALL leave the password unmodified and
+ return a non-success resultCode otherwise.
+
+ If the server does not recognize provided fields or does not support
+ the combination of fields provided, it SHALL NOT change the user
+ password.
+
+ If the provided oldPasswd value cannot be verified or is incorrect,
+ the server SHALL NOT change the user password.
+
+ The server SHALL NOT generate a password on behalf of the client if
+ the client has provided a newPassword. In absence of a client
+ provided newPassword, the server SHALL either generate a password on
+ behalf of the client or return a non-success result code. The server
+ MUST provide the generated password upon success as the value of the
+ genPasswd field.
+
+ The server MAY return adminLimitExceeded, busy,
+ confidentialityRequired, operationsError, unavailable,
+ unwillingToPerform, or other non-success resultCode as appropriate to
+ indicate that it was unable to successfully complete the operation.
+
+ Servers MAY implement administrative policies which restrict this
+ operation.
+
+
+6. Other requirements
+
+ A server which supports this operation SHOULD provide a
+
+
+
+Zeilenga [Page 4]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-passwd-exop-03 13 June 2000
+
+
+ supportedExtension attribute in the Root DSE which contains as one of
+ its values the passwdModifyOID OID. A server MAY advertise the
+ extension only when the client is authorized and/or has established
+ the necessary security protections to use this operation. Clients
+ SHOULD verify the server has advertised the extension before
+ attempting the operation.
+
+
+7. Security Considerations
+
+ This operation is used to modify user passwords. The operation itself
+ does not provide any security protection to ensure integrity and/or
+ confidentiality of the information. Use of this operation is strongly
+ discouraged when privacy protections are not in place to guarantee
+ confidentiality and may result in the disclosure of the password to
+ unauthorized parties.
+
+
+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. Bibliography
+
+
+
+
+Zeilenga [Page 5]
+\f
+INTERNET-DRAFT draft-zeilenga-ldap-passwd-exop-03 13 June 2000
+
+
+ [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.
+
+ [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.
+
+ [RFC2253] M. Wahl, S. Kille, T. Howes, "Lightweight
+ Directory Access Protocol (v3): UTF-8 String
+ Representation of Distinguished Names", RFC 2253,
+ December 1997.
+
+ [RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema
+ for use with LDAPv3", RFC 2256, December 1997.
+
+ [AuthPasswd] K. Zeilenga, "LDAP Authentication Password
+ Attribute", draft-zeilenga-ldap-authpasswd-xx.txt,
+ a work in progress.
+
+10. Acknowledgment
+
+ This document borrows from a number of IETF documents and is based
+ upon input from the IETF LDAPext working group.
+
+
+11. Author's Address
+
+ Kurt D. Zeilenga
+ OpenLDAP Foundation
+ <Kurt@OpenLDAP.org>
+
+
+
+
+
+
+
+
+
+
+
+
+
+Zeilenga [Page 6]
+\f
projects / openldap / commitdiff