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