← Back to branch summary

~ubuntu-branches/ubuntu/oneiric/likewise-open/oneiric

« back to all changes in this revision

Viewing changes to openldap/doc/rfc/rfc3062.txt

  • Committer: Bazaar Package Importer
  • Author(s): Scott Salley
  • Date: 2010-11-22 12:06:00 UTC
  • mfrom: (1.1.6 upstream)
  • Revision ID: james.westby@ubuntu.com-20101122120600-8lba1fpceot71wlb
Tags: 6.0.0.53010-1
Likewise Open 6.0

Show diffs side-by-side

added added

removed removed

Lines of Context:
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
 
 
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
 
 
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
 
 
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
 
 
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
 
 
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