git.sur5r.net Git - openldap/blob - 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