From: Kurt Zeilenga Date: Thu, 22 Feb 2001 00:45:03 +0000 (+0000) Subject: Replace I-D with RFC X-Git-Tag: LDBM_PRE_GIANT_RWLOCK~1500 X-Git-Url: https://git.sur5r.net/?a=commitdiff_plain;h=0726a493255c8ae7d93570eb380dba48164e0c0c;p=openldap Replace I-D with RFC --- diff --git a/doc/drafts/draft-zeilenga-ldap-passwd-exop-xx.txt b/doc/drafts/draft-zeilenga-ldap-passwd-exop-xx.txt deleted file mode 100644 index c446f2e6f1..0000000000 --- a/doc/drafts/draft-zeilenga-ldap-passwd-exop-xx.txt +++ /dev/null @@ -1,339 +0,0 @@ - - - - - - -INTERNET-DRAFT Kurt D. Zeilenga -Intended Category: Standard Track OpenLDAP Foundation -Expires: 3 May 2001 3 Novemeber 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 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 (e.g. Modify) cannot be used to change a user's - password. This document describes an LDAP extended operation to allow - modification of user passwords which is not dependent upon the form of - the authentication identity nor the password storage mechanism used. - - - -Zeilenga [Page 1] - -INTERNET-DRAFT draft-zeilenga-ldap-passwd-exop-05 3 Novemeber 2000 - - - 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 (e.g. userPassword), or use - non-directory storage. - - The integration [RFC2829] 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 is needed. - - This document describes an LDAP Extended Operation intended to allow - directory clients to update user passwords. The user may or may not - 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 SHALL NOT be used anonymously. - - -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 - passwdModifyOID. This section details the syntax of the protocol - - - -Zeilenga [Page 2] - -INTERNET-DRAFT draft-zeilenga-ldap-passwd-exop-05 3 Novemeber 2000 - - - request and response. - - passwdModifyOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.4203.1.11.1 - - PasswdModifyRequestValue ::= SEQUENCE { - userIdentity [0] OCTET STRING OPTIONAL - oldPasswd [1] OCTET STRING OPTIONAL - newPasswd [2] OCTET STRING OPTIONAL } - - PasswdModifyResponseValue ::= 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. - - If an resultCode other than success (0) is indicated in the response, - the response field MUST be absent. - - -5. Operation Requirements - - - -Zeilenga [Page 3] - -INTERNET-DRAFT draft-zeilenga-ldap-passwd-exop-05 3 Novemeber 2000 - - - 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 PasswdModifyOID as a value of the supportedExtension - attribute type in their root DSE. A server MAY choose to advertise - this extension only when the client is authorized and/or has - established the necessary security protections to use this operation. - Clients SHOULD verify the server implements this extended operation - prior to attempting the operation by asserting the supportedExtension - attribute contains a value of PasswdModifyOID. - - 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 oldPasswd is present and the provided value cannot be verified or - is incorrect, the server SHALL NOT change the user password. If - oldPasswd is not present, the server MAY use other policy to determine - whether or not to change the password. - - The server SHALL NOT generate a password on behalf of the client if - the client has provided a newPasswd. In absence of a client provided - newPasswd, 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. 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 - - - -Zeilenga [Page 4] - -INTERNET-DRAFT draft-zeilenga-ldap-passwd-exop-05 3 Novemeber 2000 - - - discouraged when privacy protections are not in place to guarantee - confidentiality and may result in the disclosure of the password to - unauthorized parties. Use of Start TLS [RFC 2830] is highly - recommended. - - -7. 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. - - -8. Bibliography - - [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): - - - -Zeilenga [Page 5] - -INTERNET-DRAFT draft-zeilenga-ldap-passwd-exop-05 3 Novemeber 2000 - - - 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. - - [RFC2829] M. Wahl, H. Alvestrand, J. Hodges, and R. Morgan, - "Authentication Methods for LDAP", RFC 2829, - May 2000. - - [RFC2830] Hodges, J., R. Morgan, and M. Wahl, "Lightweight - Directory Access Protocol (v3): Extension for - Transport Layer Security", RFC 2830, May 2000. - -9. Acknowledgment - - This document borrows from a number of IETF documents and is based - upon input from the IETF LDAPext working group. - - -10. Author's Address - - Kurt D. Zeilenga - OpenLDAP Foundation - - - - - - - - - - - - - - - - - - - - - - -Zeilenga [Page 6] - diff --git a/doc/rfc/rfc3062.txt b/doc/rfc/rfc3062.txt new file mode 100644 index 0000000000..ac8fd1387e --- /dev/null +++ b/doc/rfc/rfc3062.txt @@ -0,0 +1,339 @@ + + + + + + +Network Working Group K. Zeilenga +Request for Comments: 3062 OpenLDAP Foundation +Category: Standards Track February 2001 + + + LDAP Password Modify Extended Operation + +Status of this Memo + + This document specifies an Internet standards track protocol for the + Internet community, and requests discussion and suggestions for + improvements. Please refer to the current edition of the "Internet + Official Protocol Standards" (STD 1) for the standardization state + and status of this protocol. Distribution of this memo is unlimited. + +Copyright Notice + + Copyright (C) The Internet Society (2001). All Rights Reserved. + +Abstract + + The integration of the Lightweight Directory Access Protocol (LDAP) + 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 (e.g., + Modify) cannot be used to change a user's password. This document + describes an LDAP extended operation to allow modification of user + passwords which is not dependent upon the form of the authentication + identity nor the password storage 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. + +1. 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 (e.g., userPassword), or use non- + directory storage. + + + + +Zeilenga Standards Track [Page 1] + +RFC 3062 LDAP Password Modify Extended Operation February 2001 + + + The integration [RFC2829] 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 is + needed. + + This document describes an LDAP Extended Operation intended to allow + directory clients to update user passwords. The user may or may not + 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 SHALL NOT be used anonymously. + +2. 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 + passwdModifyOID. This section details the syntax of the protocol + request and response. + + passwdModifyOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.4203.1.11.1 + + PasswdModifyRequestValue ::= SEQUENCE { + userIdentity [0] OCTET STRING OPTIONAL + oldPasswd [1] OCTET STRING OPTIONAL + newPasswd [2] OCTET STRING OPTIONAL } + + PasswdModifyResponseValue ::= SEQUENCE { + genPasswd [0] OCTET STRING OPTIONAL } + +2.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. + + + + + +Zeilenga Standards Track [Page 2] + +RFC 3062 LDAP Password Modify Extended Operation February 2001 + + + 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. + +2.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. + + If an resultCode other than success (0) is indicated in the response, + the response field MUST be absent. + +3. 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 PasswdModifyOID as a value of the supportedExtension + attribute type in their root DSE. A server MAY choose to advertise + this extension only when the client is authorized and/or has + established the necessary security protections to use this operation. + Clients SHOULD verify the server implements this extended operation + prior to attempting the operation by asserting the supportedExtension + attribute contains a value of PasswdModifyOID. + + 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. + + + +Zeilenga Standards Track [Page 3] + +RFC 3062 LDAP Password Modify Extended Operation February 2001 + + + If oldPasswd is present and the provided value cannot be verified or + is incorrect, the server SHALL NOT change the user password. If + oldPasswd is not present, the server MAY use other policy to + determine whether or not to change the password. + + The server SHALL NOT generate a password on behalf of the client if + the client has provided a newPasswd. In absence of a client provided + newPasswd, 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. + +4. 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. This extension MUST be used with + confidentiality protection, such as Start TLS [RFC 2830]. The NULL + cipher suite MUST NOT be used. + +5. Bibliography + + [RFC2219] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC2222] Myers, J., "Simple Authentication and Security Layer + (SASL)", RFC 2222, October 1997. + + [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory + Access Protocol (v3)", RFC 2251, December 1997. + + [RFC2252] Wahl, M., Coulbeck, A., Howes, T. and S. Kille, + "Lightweight Directory Access Protocol (v3): Attribute + Syntax Definitions", RFC 2252, December 1997. + + + + + + +Zeilenga Standards Track [Page 4] + +RFC 3062 LDAP Password Modify Extended Operation February 2001 + + + [RFC2253] Wahl, M., Kille,S. and T. Howes, "Lightweight Directory + Access Protocol (v3): UTF-8 String Representation of + Distinguished Names", RFC 2253, December 1997. + + [RFC2256] Wahl, M., "A Summary of the X.500(96) User Schema for use + with LDAPv3", RFC 2256, December 1997. + + [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, + "Authentication Methods for LDAP", RFC 2829, May 2000. + + [RFC2830] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory + Access Protocol (v3): Extension for Transport Layer + Security", RFC 2830, May 2000. + +6. Acknowledgment + + This document borrows from a number of IETF documents and is based + upon input from the IETF LDAPext working group. + +7. Author's Address + + Kurt D. Zeilenga + OpenLDAP Foundation + + EMail: Kurt@OpenLDAP.org + + + + + + + + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 5] + +RFC 3062 LDAP Password Modify Extended Operation February 2001 + + +8. Full Copyright Statement + + Copyright (C) The Internet Society (2001). 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 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. + +Acknowledgement + + Funding for the RFC Editor function is currently provided by the + Internet Society. + + + + + + + + + + + + + + + + + + + +Zeilenga Standards Track [Page 6] +