1 2 3 4 5 6 7Network Working Group K. Zeilenga 8Request for Comments: 3112 OpenLDAP Foundation 9Category: Informational May 2001 10 11 12 LDAP Authentication Password Schema 13 14Status of this Memo 15 16 This memo provides information for the Internet community. It does 17 not specify an Internet standard of any kind. Distribution of this 18 memo is unlimited. 19 20Copyright Notice 21 22 Copyright (C) The Internet Society (2001). All Rights Reserved. 23 24Abstract 25 26 This document describes schema in support of user/password 27 authentication in a LDAP (Lightweight Directory Access Protocol) 28 directory including the authPassword attribute type. This attribute 29 type holds values derived from the user's password(s) (commonly using 30 cryptographic strength one-way hash). authPassword is intended to 31 used instead of userPassword. 32 331. Background and Intended Use 34 35 The userPassword attribute type [RFC2256] is intended to be used to 36 support the LDAP [RFC2251] "simple" bind operation. However, values 37 of userPassword must be clear text passwords. It is often desirable 38 to store values derived from the user's password(s) instead of actual 39 passwords. 40 41 The authPassword attribute type is intended to be used to store 42 information used to implement simple password based authentication. 43 The attribute type may be used by LDAP servers to implement the LDAP 44 Bind operation's "simple" authentication method. 45 46 The attribute type supports multiple storage schemes. A matching 47 rule is provided for use with extensible search filters to allow 48 clients to assert that a clear text password "matches" one of the 49 attribute's values. 50 51 Storage schemes often use cryptographic strength one-way hashing. 52 Though the use of one-way hashing reduces the potential that exposed 53 values will allow unauthorized access to the Directory (unless the 54 55 56 57 58Zeilenga Informational [Page 1] 59 60RFC 3112 LDAP Authentication Password Schema May 2001 61 62 63 hash algorithm/implementation is flawed), the hashing of passwords is 64 intended to be as an additional layer of protection. It is 65 RECOMMENDED that hashed values be protected as if they were clear 66 text passwords. 67 68 This attribute may be used in conjunction with server side password 69 generation mechanisms (such as the LDAP Password Modify [RFC3062] 70 extended operation). 71 72 Access to this attribute may governed by administrative controls such 73 as those which implement password change policies. 74 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document are 77 to be interpreted as described in RFC 2119 [RFC2119]. 78 792. Schema Definitions 80 81 The following schema definitions are described in terms of LDAPv3 82 Attribute Syntax Definitions [RFC2252] with specific syntax detailed 83 using Augmented BNF [RFC2234]. 84 852.1. authPasswordSyntax 86 87 ( 1.3.6.1.4.1.4203.1.1.2 88 DESC 'authentication password syntax' ) 89 90 Values of this syntax are encoded according to: 91 92 authPasswordValue = w scheme s authInfo s authValue w 93 scheme = %x30-39 / %x41-5A / %x2D-2F / %x5F 94 ; 0-9, A-Z, "-", ".", "/", or "_" 95 authInfo = schemeSpecificValue 96 authValue = schemeSpecificValue 97 schemeSpecificValue = *( %x21-23 / %x25-7E ) 98 ; printable ASCII less "$" and " " 99 s = w SEP w 100 w = *SP 101 SEP = %x24 ; "$" 102 SP = %x20 ; " " (space) 103 104 where scheme describes the mechanism and authInfo and authValue are a 105 scheme specific. The authInfo field is often a base64 encoded salt. 106 The authValue field is often a base64 encoded value derived from a 107 user's password(s). Values of this attribute are case sensitive. 108 109 110 111 112 113 114Zeilenga Informational [Page 2] 115 116RFC 3112 LDAP Authentication Password Schema May 2001 117 118 119 Transfer of values of this syntax is strongly discouraged where the 120 underlying transport service cannot guarantee confidentiality and may 121 result in disclosure of the values to unauthorized parties. 122 123 This document describes a number of schemes, as well as requirements 124 for the scheme naming, in section 3. 125 1262.2. authPasswordExactMatch 127 128 ( 1.3.6.1.4.1.4203.1.2.2 129 NAME 'authPasswordExactMatch' 130 DESC 'authentication password exact matching rule' 131 SYNTAX 1.3.6.1.4.1.4203.1.1.2 ) 132 133 This matching rule allows a client to assert that an asserted 134 authPasswordSyntax value matches authPasswordSyntax values. It is 135 meant to be used as the EQUALITY matching rule of attributes whose 136 SYNTAX is authPasswordSyntax. 137 138 The assertion is "TRUE" if there is an attribute value which has the 139 same scheme, authInfo, and authValue components as the asserted 140 value; "FALSE" if no attribute value has the same components as the 141 asserted value; and "Undefined" otherwise. 142 1432.3. authPasswordMatch 144 145 ( 1.3.6.1.4.1.4203.1.2.3 146 NAME 'authPasswordMatch' 147 DESC 'authentication password matching rule' 148 SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} ) 149 150 This matching rule allows a client to assert that a password matches 151 values of authPasswordSyntax using an extensibleMatch filter 152 component. Each value is matched per its scheme. The assertion is 153 "TRUE" if one or more attribute values matches the asserted value, 154 "FALSE" if all values do not matches, and "Undefined" otherwise. 155 156 Servers which support use of this matching rule SHOULD publish 157 appropriate matchingRuleUse values per [RFC2252], 4.4. 158 159 Transfer of authPasswordMatch assertion values is strongly 160 discouraged where the underlying transport service cannot guarantee 161 confidentiality and may result in disclosure of the values to 162 unauthorized parties. 163 164 165 166 167 168 169 170Zeilenga Informational [Page 3] 171 172RFC 3112 LDAP Authentication Password Schema May 2001 173 174 1752.4. supportedAuthPasswordSchemes 176 177 ( 1.3.6.1.4.1.4203.1.3.3 178 NAME 'supportedAuthPasswordSchemes' 179 DESC 'supported password storage schemes' 180 EQUALITY caseExactIA5Match 181 SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32} 182 USAGE dSAOperation ) 183 184 The values of this attribute are names of supported authentication 185 password schemes which the server supports. The syntax of a scheme 186 name is described in section 2.1. This attribute may only be present 187 in the root DSE. If the server does not support any password 188 schemes, this attribute will not be present. 189 1902.5. authPassword 191 192 ( 1.3.6.1.4.1.4203.1.3.4 NAME 'authPassword' 193 DESC 'password authentication information' 194 EQUALITY 1.3.6.1.4.1.4203.1.2.2 195 SYNTAX 1.3.6.1.4.1.4203.1.1.2 ) 196 197 The values of this attribute are representative of the user's 198 password(s) and conform to the authPasswordSyntax described in 2.1. 199 The values of this attribute may be used for authentication purposes. 200 201 Transfer of authPassword values is strongly discouraged where the 202 underlying transport service cannot guarantee confidentiality and may 203 result in disclosure of the values to unauthorized parties. 204 2052.6. authPasswordObject 206 207 ( 1.3.6.1.4.1.4203.1.4.7 NAME 'authPasswordObject' 208 DESC 'authentication password mix in class' 209 MAY 'authPassword' 210 AUXILIARY ) 211 212 Entries of this object class may contain authPassword attribute 213 types. 214 2153. Schemes 216 217 This section describes the "MD5" and "SHA1" schemes. Other schemes 218 may be defined by other documents. Schemes which are not described 219 in an RFC SHOULD be named with a leading "X-" to indicate they are a 220 private or implementation specific scheme, or may be named using the 221 dotted-decimal representation [RFC2252] of an OID assigned to the 222 scheme. 223 224 225 226Zeilenga Informational [Page 4] 227 228RFC 3112 LDAP Authentication Password Schema May 2001 229 230 2313.1. MD5 scheme 232 233 The MD5 [RFC1321] scheme name is "MD5". 234 235 The authValue is the base64 encoding of an MD5 digest of the 236 concatenation the user password and salt. The base64 encoding of the 237 salt is provided in the authInfo field. The salt MUST be at least 64 238 bits long. Implementations of this scheme MUST support salts up to 239 128 bits in length. 240 241 Example: 242 Given a user "joe" who's password is "mary" and a salt of "salt", 243 the authInfo field would be the base64 encoding of "salt" and the 244 authValue field would be the base64 encoding of the MD5 digest of 245 "marysalt". 246 247 A match against an asserted password and an attribute value of this 248 scheme SHALL be true if and only if the MD5 digest of concatenation 249 of the asserted value and the salt is equal to the MD5 digest 250 contained in AuthValue. The match SHALL be undefined if the server 251 is unable to complete the equality test for any reason. Otherwise 252 the match SHALL be false. 253 254 Values of this scheme SHOULD only be used to implement simple 255 user/password authentication. 256 2573.2. SHA1 scheme 258 259 The SHA1 [SHA1] scheme name is "SHA1". 260 261 The authValue is the base64 encoding of a SHA1 digest of the 262 concatenation the user password and the salt. The base64 encoding of 263 the salt is provided in the authInfo field. The salt MUST be at 264 least 64 bits long. Implementations of this scheme MUST support 265 salts up to 128 bits in length. 266 267 Example: 268 Given a user "joe" who's password is "mary" and a salt of "salt", 269 the authInfo field would be the base64 encoding of "salt" and the 270 authValue field would be the base64 encoding of the SHA1 digest of 271 "marysalt". 272 273 A match against an asserted password and an attribute value of this 274 scheme SHALL be true if and only if the SHA1 digest of concatenation 275 of the asserted value and the salt is equal to the SHA1 digest 276 contained in AuthValue. The match SHALL be undefined if the server 277 is unable to complete the equality test for any reason. Otherwise 278 the match SHALL be false. 279 280 281 282Zeilenga Informational [Page 5] 283 284RFC 3112 LDAP Authentication Password Schema May 2001 285 286 287 Values of this scheme SHOULD only be used to implement simple 288 user/password authentication. 289 2904. Implementation Issues 291 292 For all implementations of this specification: 293 294 Servers MAY restrict which schemes are used in conjunction with a 295 particular authentication process but SHOULD use all values of 296 selected schemes. If the asserted password matches any of the 297 stored values, the asserted password SHOULD be considered valid. 298 Servers MAY use other authentication storage mechanisms, such as 299 userPassword or an external password store, in conjunction with 300 authPassword to support the authentication process. 301 302 Servers that support simple bind MUST support the SHA1 scheme and 303 SHOULD support the MD5 scheme. 304 305 Servers SHOULD NOT publish values of authPassword nor allow 306 operations which expose authPassword values or AuthPasswordMatch 307 assertions to unless confidentiality protection is in place. 308 309 Clients SHOULD NOT initiate operations which provide or request 310 values of authPassword or make authPasswordMatch assertions unless 311 confidentiality protection is in place. 312 313 Clients SHOULD NOT assume that a successful AuthPasswordMatch, 314 whether by compare or search, is sufficient to gain directory 315 access. The bind operation MUST be used to authenticate to the 316 directory. 317 3185. Security Considerations 319 320 This document describes how authentication information may be stored 321 in a directory. Authentication information MUST be adequately 322 protected as unintended disclosure will allow attackers to gain 323 immediate access to the directory as described by [RFC2829]. 324 325 As flaws may be discovered in the hashing algorithm or with a 326 particular implementation of the algorithm or values could be subject 327 to various attacks if exposed, values of AuthPassword SHOULD be 328 protected as if they were clear text passwords. When values are 329 transferred, privacy protections, such as IPSEC or TLS, SHOULD be in 330 place. 331 332 Clients SHOULD use strong authentication mechanisms [RFC2829]. 333 334 335 336 337 338Zeilenga Informational [Page 6] 339 340RFC 3112 LDAP Authentication Password Schema May 2001 341 342 343 AuthPasswordMatch matching rule allows applications to test the 344 validity of a user password and, hence, may be used to mount an 345 attack. Servers SHOULD take appropriate measures to protect the 346 directory from such attacks. 347 348 Some password schemes may require CPU intensive operations. Servers 349 SHOULD take appropriate measures to protect against Denial of Service 350 attacks. 351 352 AuthPassword does not restrict an authentication identity to a single 353 password. An attacker who gains write access to this attribute may 354 store additional values without disabling the user's true 355 password(s). Use of policy aware clients and servers is RECOMMENDED. 356 357 The level of protection offered against various attacks differ from 358 scheme to scheme. It is RECOMMENDED that servers support scheme 359 selection as a configuration item. This allows for a scheme to be 360 easily disabled if a significant security flaw is discovered. 361 3626. Acknowledgment 363 364 This document borrows from a number of IETF documents and is based 365 upon input from the IETF LDAPext working group. 366 3677. Bibliography 368 369 [RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321, 370 April 1992 371 372 [RFC2219] Bradner, S., "Key words for use in RFCs to Indicate 373 Requirement Levels", BCP 14, RFC 2119, March 1997. 374 375 [RFC2234] Crocker, D., Editor, P. Overell, "Augmented BNF for Syntax 376 Specifications: ABNF", RFC 2234, November 1997. 377 378 [RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory 379 Access Protocol (v3)", RFC 2251, December 1997. 380 381 [RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille, 382 "Lightweight Directory Access Protocol (v3): Attribute 383 Syntax Definitions", RFC 2252, December 1997. 384 385 [RFC2256] Wahl, A., "A Summary of the X.500(96) User Schema for use 386 with LDAPv3", RFC 2256, December 1997. 387 388 [RFC2307] Howard, L., "An Approach for Using LDAP as a Network 389 Information Service", RFC 2307, March 1998. 390 391 392 393 394Zeilenga Informational [Page 7] 395 396RFC 3112 LDAP Authentication Password Schema May 2001 397 398 399 [RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan, 400 "Authentication Methods for LDAP", RFC 2829, June 2000. 401 402 [RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation", 403 RFC 3062, February 2001. 404 405 [SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995. 406 4078. Author's Address 408 409 Kurt D. Zeilenga 410 OpenLDAP Foundation 411 412 EMail: Kurt@OpenLDAP.org 413 414 415 416 417 418 419 420 421 422 423 424 425 426 427 428 429 430 431 432 433 434 435 436 437 438 439 440 441 442 443 444 445 446 447 448 449 450Zeilenga Informational [Page 8] 451 452RFC 3112 LDAP Authentication Password Schema May 2001 453 454 4559. Full Copyright Statement 456 457 Copyright (C) The Internet Society (2001). All Rights Reserved. 458 459 This document and translations of it may be copied and furnished to 460 others, and derivative works that comment on or otherwise explain it 461 or assist in its implementation may be prepared, copied, published 462 and distributed, in whole or in part, without restriction of any 463 kind, provided that the above copyright notice and this paragraph are 464 included on all such copies and derivative works. However, this 465 document itself may not be modified in any way, such as by removing 466 the copyright notice or references to the Internet Society or other 467 Internet organizations, except as needed for the purpose of 468 developing Internet standards in which case the procedures for 469 copyrights defined in the Internet Standards process must be 470 followed, or as required to translate it into languages other than 471 English. 472 473 The limited permissions granted above are perpetual and will not be 474 revoked by the Internet Society or its successors or assigns. 475 476 This document and the information contained herein is provided on an 477 "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING 478 TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING 479 BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION 480 HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF 481 MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 482 483Acknowledgement 484 485 Funding for the RFC Editor function is currently provided by the 486 Internet Society. 487 488 489 490 491 492 493 494 495 496 497 498 499 500 501 502 503 504 505 506Zeilenga Informational [Page 9] 507 508