1
2
3
4
5
6
7Network Working Group                                        K. Zeilenga
8Request for Comments: 3062                           OpenLDAP Foundation
9Category: Standards Track                                  February 2001
10
11
12                LDAP Password Modify Extended Operation
13
14Status of this Memo
15
16   This document specifies an Internet standards track protocol for the
17   Internet community, and requests discussion and suggestions for
18   improvements.  Please refer to the current edition of the "Internet
19   Official Protocol Standards" (STD 1) for the standardization state
20   and status of this protocol.  Distribution of this memo is unlimited.
21
22Copyright Notice
23
24   Copyright (C) The Internet Society (2001).  All Rights Reserved.
25
26Abstract
27
28   The integration of the Lightweight Directory Access Protocol (LDAP)
29   and external authentication services has introduced non-DN
30   authentication identities and allowed for non-directory storage of
31   passwords.  As such, mechanisms which update the directory (e.g.,
32   Modify) cannot be used to change a user's password.  This document
33   describes an LDAP extended operation to allow modification of user
34   passwords which is not dependent upon the form of the authentication
35   identity nor the password storage mechanism used.
36
37   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
38   "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are
39   to be interpreted as described in RFC 2119.
40
411.  Background and Intent of Use
42
43   Lightweight Directory Access Protocol (LDAP) [RFC2251] is designed to
44   support an number of authentication mechanisms including simple user
45   name/password pairs.  Traditionally, LDAP users where identified by
46   the Distinguished Name [RFC2253] of a directory entry and this entry
47   contained a userPassword [RFC2256] attribute containing one or more
48   passwords.
49
50   The protocol does not mandate that passwords associated with a user
51   be stored in the directory server.  The server may use any attribute
52   suitable for password storage (e.g., userPassword), or use non-
53   directory storage.
54
55
56
57
58Zeilenga                    Standards Track                     [Page 1]
59
60RFC 3062        LDAP Password Modify Extended Operation    February 2001
61
62
63   The integration [RFC2829] of application neutral SASL [RFC2222]
64   services which support simple username/password mechanisms (such as
65   DIGEST-MD5) has introduced non-LDAP DN authentication identity forms
66   and made storage of passwords the responsibility of the SASL service
67   provider.
68
69   LDAP update operations are designed to act upon attributes of an
70   entry within the directory.  LDAP update operations cannot be used to
71   modify a user's password when the user is not represented by a DN,
72   does not have a entry, or when that password used by the server is
73   not stored as an attribute of an entry.  An alternative mechanism is
74   needed.
75
76   This document describes an LDAP Extended Operation intended to allow
77   directory clients to update user passwords.  The user may or may not
78   be associated with a directory entry.  The user may or may not be
79   represented as an LDAP DN.  The user's password may or may not be
80   stored in the directory.
81
82   The operation SHOULD NOT be used without adequate security protection
83   as the operation affords no privacy or integrity protect itself.
84   This operation SHALL NOT be used anonymously.
85
862.  Password Modify Request and Response
87
88   The Password Modify operation is an LDAPv3 Extended Operation
89   [RFC2251, Section 4.12] and is identified by the OBJECT IDENTIFIER
90   passwdModifyOID.  This section details the syntax of the protocol
91   request and response.
92
93   passwdModifyOID OBJECT IDENTIFIER ::= 1.3.6.1.4.1.4203.1.11.1
94
95   PasswdModifyRequestValue ::= SEQUENCE {
96     userIdentity    [0]  OCTET STRING OPTIONAL
97     oldPasswd       [1]  OCTET STRING OPTIONAL
98     newPasswd       [2]  OCTET STRING OPTIONAL }
99
100   PasswdModifyResponseValue ::= SEQUENCE {
101     genPasswd       [0]     OCTET STRING OPTIONAL }
102
1032.1.  Password Modify Request
104
105   A Password Modify request is an ExtendedRequest with the requestName
106   field containing passwdModifyOID OID and optionally provides a
107   requestValue field.  If the requestValue field is provided, it SHALL
108   contain a PasswdModifyRequestValue with one or more fields present.
109
110
111
112
113
114Zeilenga                    Standards Track                     [Page 2]
115
116RFC 3062        LDAP Password Modify Extended Operation    February 2001
117
118
119   The userIdentity field, if present, SHALL contain an octet string
120   representation of the user associated with the request.  This string
121   may or may not be an LDAPDN [RFC2253].  If no userIdentity field is
122   present, the request acts up upon the password of the user currently
123   associated with the LDAP session.
124
125   The oldPasswd field, if present, SHALL contain the user's current
126   password.
127
128   The newPasswd field, if present, SHALL contain the desired password
129   for this user.
130
1312.2.  Password Modify Response
132
133   A Password Modify response is an ExtendedResponse where the
134   responseName field is absent and the response field is optional.  The
135   response field, if present, SHALL contain a PasswdModifyResponseValue
136   with genPasswd field present.
137
138   The genPasswd field, if present, SHALL contain a generated password
139   for the user.
140
141   If an resultCode other than success (0) is indicated in the response,
142   the response field MUST be absent.
143
1443.  Operation Requirements
145
146   Clients SHOULD NOT submit a Password Modification request without
147   ensuring adequate security safeguards are in place.  Servers SHOULD
148   return a non-success resultCode if sufficient security protection are
149   not in place.
150
151   Servers SHOULD indicate their support for this extended operation by
152   providing PasswdModifyOID as a value of the supportedExtension
153   attribute type in their root DSE.  A server MAY choose to advertise
154   this extension only when the client is authorized and/or has
155   established the necessary security protections to use this operation.
156   Clients SHOULD verify the server implements this extended operation
157   prior to attempting the operation by asserting the supportedExtension
158   attribute contains a value of PasswdModifyOID.
159
160   The server SHALL only return success upon successfully changing the
161   user's password.  The server SHALL leave the password unmodified and
162   return a non-success resultCode otherwise.
163
164   If the server does not recognize provided fields or does not support
165   the combination of fields provided, it SHALL NOT change the user
166   password.
167
168
169
170Zeilenga                    Standards Track                     [Page 3]
171
172RFC 3062        LDAP Password Modify Extended Operation    February 2001
173
174
175   If oldPasswd is present and the provided value cannot be verified or
176   is incorrect, the server SHALL NOT change the user password.  If
177   oldPasswd is not present, the server MAY use other policy to
178   determine whether or not to change the password.
179
180   The server SHALL NOT generate a password on behalf of the client if
181   the client has provided a newPasswd.  In absence of a client provided
182   newPasswd, the server SHALL either generate a password on behalf of
183   the client or return a non-success result code.  The server MUST
184   provide the generated password upon success as the value of the
185   genPasswd field.
186
187   The server MAY return adminLimitExceeded, busy,
188   confidentialityRequired, operationsError, unavailable,
189   unwillingToPerform, or other non-success resultCode as appropriate to
190   indicate that it was unable to successfully complete the operation.
191
192   Servers MAY implement administrative policies which restrict this
193   operation.
194
1954.  Security Considerations
196
197   This operation is used to modify user passwords.  The operation
198   itself does not provide any security protection to ensure integrity
199   and/or confidentiality of the information.  Use of this operation is
200   strongly discouraged when privacy protections are not in place to
201   guarantee confidentiality and may result in the disclosure of the
202   password to unauthorized parties.  This extension MUST be used with
203   confidentiality protection, such as Start TLS [RFC 2830].  The NULL
204   cipher suite MUST NOT be used.
205
2065. Bibliography
207
208   [RFC2219]  Bradner, S., "Key words for use in RFCs to Indicate
209              Requirement Levels", BCP 14, RFC 2119, March 1997.
210
211   [RFC2222]  Myers, J., "Simple Authentication and Security Layer
212              (SASL)", RFC 2222, October 1997.
213
214   [RFC2251]  Wahl, M., Howes, T. and S. Kille, "Lightweight Directory
215              Access Protocol (v3)", RFC 2251, December 1997.
216
217   [RFC2252]  Wahl, M., Coulbeck, A., Howes, T. and S. Kille,
218              "Lightweight Directory Access Protocol (v3): Attribute
219              Syntax Definitions", RFC 2252, December 1997.
220
221
222
223
224
225
226Zeilenga                    Standards Track                     [Page 4]
227
228RFC 3062        LDAP Password Modify Extended Operation    February 2001
229
230
231   [RFC2253]  Wahl, M., Kille,S. and T. Howes, "Lightweight Directory
232              Access Protocol (v3): UTF-8 String Representation of
233              Distinguished Names", RFC 2253, December 1997.
234
235   [RFC2256]  Wahl, M., "A Summary of the X.500(96) User Schema for use
236              with LDAPv3", RFC 2256, December 1997.
237
238   [RFC2829]  Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
239              "Authentication Methods for LDAP", RFC 2829, May 2000.
240
241   [RFC2830]  Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory
242              Access Protocol (v3): Extension for Transport Layer
243              Security", RFC 2830, May 2000.
244
2456.  Acknowledgment
246
247   This document borrows from a number of IETF documents and is based
248   upon input from the IETF LDAPext working group.
249
2507.  Author's Address
251
252   Kurt D. Zeilenga
253   OpenLDAP Foundation
254
255   EMail: Kurt@OpenLDAP.org
256
257
258
259
260
261
262
263
264
265
266
267
268
269
270
271
272
273
274
275
276
277
278
279
280
281
282Zeilenga                    Standards Track                     [Page 5]
283
284RFC 3062        LDAP Password Modify Extended Operation    February 2001
285
286
2878.  Full Copyright Statement
288
289   Copyright (C) The Internet Society (2001).  All Rights Reserved.
290
291   This document and translations of it may be copied and furnished to
292   others, and derivative works that comment on or otherwise explain it
293   or assist in its implementation may be prepared, copied, published
294   and distributed, in whole or in part, without restriction of any
295   kind, provided that the above copyright notice and this paragraph are
296   included on all such copies and derivative works.  However, this
297   document itself may not be modified in any way, such as by removing
298   the copyright notice or references to the Internet Society or other
299   Internet organizations, except as needed for the purpose of
300   developing Internet standards in which case the procedures for
301   copyrights defined in the Internet Standards process must be
302   followed, or as required to translate it into languages other than
303   English.
304
305   The limited permissions granted above are perpetual and will not be
306   revoked by the Internet Society or its successors or assigns.
307
308   This document and the information contained herein is provided on an
309   "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
310   TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
311   BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
312   HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
313   MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
314
315Acknowledgement
316
317   Funding for the RFC Editor function is currently provided by the
318   Internet Society.
319
320
321
322
323
324
325
326
327
328
329
330
331
332
333
334
335
336
337
338Zeilenga                    Standards Track                     [Page 6]
339
340