From 7bc9587daa264747825cfd3c5bf44d29ddecbdf6 Mon Sep 17 00:00:00 2001 From: Kurt Zeilenga Date: Fri, 7 Jul 2000 20:03:15 +0000 Subject: [PATCH] Add password extended operation draft --- .../draft-zeilenga-ldap-passwd-exop-xx.txt | 333 ++++++++++++++++++ 1 file changed, 333 insertions(+) create mode 100644 doc/drafts/draft-zeilenga-ldap-passwd-exop-xx.txt diff --git a/doc/drafts/draft-zeilenga-ldap-passwd-exop-xx.txt b/doc/drafts/draft-zeilenga-ldap-passwd-exop-xx.txt new file mode 100644 index 0000000000..ea160b6a2e --- /dev/null +++ b/doc/drafts/draft-zeilenga-ldap-passwd-exop-xx.txt @@ -0,0 +1,333 @@ +INTERNET-DRAFT Kurt D. Zeilenga +Intended Category: Standard Track OpenLDAP Foundation +Expires: 13 December 2000 13 June 2000 + + + LDAP Password Modify Extended Operation + + + +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 + + 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] + +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] + +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] + +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] + +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] + +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 + + + + + + + + + + + + + + +Zeilenga [Page 6] + -- 2.39.5