]> git.sur5r.net Git - openldap/blob - doc/rfc/rfc3062.txt
Remove many (but not all) references to slurpd(8).
[openldap] / doc / rfc / rfc3062.txt
1
2
3
4
5
6
7 Network Working Group                                        K. Zeilenga
8 Request for Comments: 3062                           OpenLDAP Foundation
9 Category: Standards Track                                  February 2001
10
11
12                 LDAP Password Modify Extended Operation
13
14 Status 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
22 Copyright Notice
23
24    Copyright (C) The Internet Society (2001).  All Rights Reserved.
25
26 Abstract
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
41 1.  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
58 Zeilenga                    Standards Track                     [Page 1]
59 \f
60 RFC 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
86 2.  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
103 2.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
114 Zeilenga                    Standards Track                     [Page 2]
115 \f
116 RFC 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
131 2.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
144 3.  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
170 Zeilenga                    Standards Track                     [Page 3]
171 \f
172 RFC 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
195 4.  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
206 5. 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
226 Zeilenga                    Standards Track                     [Page 4]
227 \f
228 RFC 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
245 6.  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
250 7.  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
282 Zeilenga                    Standards Track                     [Page 5]
283 \f
284 RFC 3062        LDAP Password Modify Extended Operation    February 2001
285
286
287 8.  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
315 Acknowledgement
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
338 Zeilenga                    Standards Track                     [Page 6]
339 \f