As per Relevance of the word password, we have this rfc below:
Network Working Group K.
Request for Comments: 3112 OpenLDAP
Category: Informational May 2001
LDAP Authentication Password
Status of this
This memo provides information for the Internet community. It
not specify an Internet standard of any kind. Distribution of
memo is unlimited
Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document describes schema in support of user/
authentication in a LDAP (Lightweight Directory Access Protocol
directory including the authPassword attribute type. This
type holds values derived from the user's password(s) (commonly
cryptographic strength one-way hash). authPassword is intended
used instead of userPassword
1. Background and Intended
The userPassword attribute type [RFC2256] is intended to be used
support the LDAP [RFC2251] "simple" bind operation. However,
of userPassword must be clear text passwords. It is often
to store values derived from the user's password(s) instead of
passwords
The authPassword attribute type is intended to be used to
information used to implement simple password based authentication
The attribute type may be used by LDAP servers to implement the
Bind operation's "simple" authentication method
The attribute type supports multiple storage schemes. A
rule is provided for use with extensible search filters to
clients to assert that a clear text password "matches" one of
attribute's values
Storage schemes often use cryptographic strength one-way hashing
Though the use of one-way hashing reduces the potential that
values will allow unauthorized access to the Directory (unless
Zeilenga Informational [Page 1]
RFC 3112 LDAP Authentication Password Schema May 2001
hash algorithm/implementation is flawed), the hashing of passwords
intended to be as an additional layer of protection. It
RECOMMENDED that hashed values be protected as if they were
text passwords
This attribute may be used in conjunction with server side
generation mechanisms (such as the LDAP Password Modify [RFC3062]
extended operation).
Access to this attribute may governed by administrative controls
as those which implement password change policies
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", and "MAY" in this document
to be interpreted as described in RFC 2119 [RFC2119].
2. Schema
The following schema definitions are described in terms of LDAPv
Attribute Syntax Definitions [RFC2252] with specific syntax
using Augmented BNF [RFC2234].
2.1.
( 1.3.6.1.4.1.4203.1.1.2
DESC 'authentication password syntax' )
Values of this syntax are encoded according to
authPasswordValue = w scheme s authInfo s authValue
scheme = %x30-39 / %x41-5A / %x2D-2F / %x5
; 0-9, A-Z, "-", ".", "/", or "_"
authInfo =
authValue =
schemeSpecificValue = *( %x21-23 / %x25-7E )
; printable ASCII less "$" and " "
s = w SEP
w = *
SEP = %x24 ; "$"
SP = %x20 ; " " (space
where scheme describes the mechanism and authInfo and authValue are
scheme specific. The authInfo field is often a base64 encoded salt
The authValue field is often a base64 encoded value derived from
user's password(s). Values of this attribute are case sensitive
Zeilenga Informational [Page 2]
RFC 3112 LDAP Authentication Password Schema May 2001
Transfer of values of this syntax is strongly discouraged where
underlying transport service cannot guarantee confidentiality and
result in disclosure of the values to unauthorized parties
This document describes a number of schemes, as well as
for the scheme naming, in section 3.
2.2.
( 1.3.6.1.4.1.4203.1.2.2
NAME 'authPasswordExactMatch
DESC 'authentication password exact matching rule
SYNTAX 1.3.6.1.4.1.4203.1.1.2 )
This matching rule allows a client to assert that an
authPasswordSyntax value matches authPasswordSyntax values. It
meant to be used as the EQUALITY matching rule of attributes
SYNTAX is authPasswordSyntax
The assertion is "TRUE" if there is an attribute value which has
same scheme, authInfo, and authValue components as the
value; "FALSE" if no attribute value has the same components as
asserted value; and "Undefined" otherwise
2.3.
( 1.3.6.1.4.1.4203.1.2.3
NAME 'authPasswordMatch
DESC 'authentication password matching rule
SYNTAX 1.3.6.1.4.1.1466.115.121.1.40{128} )
This matching rule allows a client to assert that a password
values of authPasswordSyntax using an extensibleMatch
component. Each value is matched per its scheme. The assertion
"TRUE" if one or more attribute values matches the asserted value
"FALSE" if all values do not matches, and "Undefined" otherwise
Servers which support use of this matching rule SHOULD
appropriate matchingRuleUse values per [RFC2252], 4.4.
Transfer of authPasswordMatch assertion values is
discouraged where the underlying transport service cannot
confidentiality and may result in disclosure of the values
unauthorized parties
Zeilenga Informational [Page 3]
RFC 3112 LDAP Authentication Password Schema May 2001
2.4.
( 1.3.6.1.4.1.4203.1.3.3
NAME 'supportedAuthPasswordSchemes
DESC 'supported password storage schemes
EQUALITY caseExactIA5
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32}
USAGE dSAOperation )
The values of this attribute are names of supported
password schemes which the server supports. The syntax of a
name is described in section 2.1. This attribute may only be
in the root DSE. If the server does not support any
schemes, this attribute will not be present
2.5.
( 1.3.6.1.4.1.4203.1.3.4 NAME 'authPassword
DESC 'password authentication information
EQUALITY 1.3.6.1.4.1.4203.1.2.2
SYNTAX 1.3.6.1.4.1.4203.1.1.2 )
The values of this attribute are representative of the user'
password(s) and conform to the authPasswordSyntax described in 2.1.
The values of this attribute may be used for authentication purposes
Transfer of authPassword values is strongly discouraged where
underlying transport service cannot guarantee confidentiality and
result in disclosure of the values to unauthorized parties
2.6.
( 1.3.6.1.4.1.4203.1.4.7 NAME 'authPasswordObject
DESC 'authentication password mix in class
MAY 'authPassword
AUXILIARY )
Entries of this object class may contain authPassword
types
3.
This section describes the "MD5" and "SHA1" schemes. Other
may be defined by other documents. Schemes which are not
in an RFC SHOULD be named with a leading "X-" to indicate they are
private or implementation specific scheme, or may be named using
dotted-decimal representation [RFC2252] of an OID assigned to
scheme
Zeilenga Informational [Page 4]
RFC 3112 LDAP Authentication Password Schema May 2001
3.1. MD5
The MD5 [RFC1321] scheme name is "MD5".
The authValue is the base64 encoding of an MD5 digest of
concatenation the user password and salt. The base64 encoding of
salt is provided in the authInfo field. The salt MUST be at least 64
bits long. Implementations of this scheme MUST support salts up
128 bits in length
Example
Given a user "joe" who's password is "mary" and a salt of "salt",
the authInfo field would be the base64 encoding of "salt" and
authValue field would be the base64 encoding of the MD5 digest
"marysalt".
A match against an asserted password and an attribute value of
scheme SHALL be true if and only if the MD5 digest of
of the asserted value and the salt is equal to the MD5
contained in AuthValue. The match SHALL be undefined if the
is unable to complete the equality test for any reason.
the match SHALL be false
Values of this scheme SHOULD only be used to implement
user/password authentication
3.2. SHA1
The SHA1 [SHA1] scheme name is "SHA1".
The authValue is the base64 encoding of a SHA1 digest of
concatenation the user password and the salt. The base64 encoding
the salt is provided in the authInfo field. The salt MUST be
least 64 bits long. Implementations of this scheme MUST
salts up to 128 bits in length
Example
Given a user "joe" who's password is "mary" and a salt of "salt",
the authInfo field would be the base64 encoding of "salt" and
authValue field would be the base64 encoding of the SHA1 digest
"marysalt".
A match against an asserted password and an attribute value of
scheme SHALL be true if and only if the SHA1 digest of
of the asserted value and the salt is equal to the SHA1
contained in AuthValue. The match SHALL be undefined if the
is unable to complete the equality test for any reason.
the match SHALL be false
Zeilenga Informational [Page 5]
RFC 3112 LDAP Authentication Password Schema May 2001
Values of this scheme SHOULD only be used to implement
user/password authentication
4. Implementation
For all implementations of this specification
Servers MAY restrict which schemes are used in conjunction with
particular authentication process but SHOULD use all values
selected schemes. If the asserted password matches any of
stored values, the asserted password SHOULD be considered valid
Servers MAY use other authentication storage mechanisms, such
userPassword or an external password store, in conjunction
authPassword to support the authentication process
Servers that support simple bind MUST support the SHA1 scheme
SHOULD support the MD5 scheme
Servers SHOULD NOT publish values of authPassword nor
operations which expose authPassword values or
assertions to unless confidentiality protection is in place
Clients SHOULD NOT initiate operations which provide or
values of authPassword or make authPasswordMatch assertions
confidentiality protection is in place
Clients SHOULD NOT assume that a successful AuthPasswordMatch
whether by compare or search, is sufficient to gain
access. The bind operation MUST be used to authenticate to
directory
5. Security
This document describes how authentication information may be
in a directory. Authentication information MUST be
protected as unintended disclosure will allow attackers to
immediate access to the directory as described by [RFC2829].
As flaws may be discovered in the hashing algorithm or with
particular implementation of the algorithm or values could be
to various attacks if exposed, values of AuthPassword SHOULD
protected as if they were clear text passwords. When values
transferred, privacy protections, such as IPSEC or TLS, SHOULD be
place
Clients SHOULD use strong authentication mechanisms [RFC2829].
Zeilenga Informational [Page 6]
RFC 3112 LDAP Authentication Password Schema May 2001
AuthPasswordMatch matching rule allows applications to test
validity of a user password and, hence, may be used to mount
attack. Servers SHOULD take appropriate measures to protect
directory from such attacks
Some password schemes may require CPU intensive operations.
SHOULD take appropriate measures to protect against Denial of
attacks
AuthPassword does not restrict an authentication identity to a
password. An attacker who gains write access to this attribute
store additional values without disabling the user's
password(s). Use of policy aware clients and servers is RECOMMENDED
The level of protection offered against various attacks differ
scheme to scheme. It is RECOMMENDED that servers support
selection as a configuration item. This allows for a scheme to
easily disabled if a significant security flaw is discovered
6.
This document borrows from a number of IETF documents and is
upon input from the IETF LDAPext working group
7.
[RFC1321] Rivest, R., "The MD5 Message-Digest Algorithm", RFC 1321,
April 1992
[RFC2219] Bradner, S., "Key words for use in RFCs to
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2234] Crocker, D., Editor, P. Overell, "Augmented BNF for
Specifications: ABNF", RFC 2234, November 1997.
[RFC2251] Wahl, M., Howes, T. and S. Kille, "Lightweight
Access Protocol (v3)", RFC 2251, December 1997.
[RFC2252] Wahl, M., Coulbeck, A., Howes, T., and S. Kille
"Lightweight Directory Access Protocol (v3):
Syntax Definitions", RFC 2252, December 1997.
[RFC2256] Wahl, A., "A Summary of the X.500(96) User Schema for
with LDAPv3", RFC 2256, December 1997.
[RFC2307] Howard, L., "An Approach for Using LDAP as a
Information Service", RFC 2307, March 1998.
Zeilenga Informational [Page 7]
RFC 3112 LDAP Authentication Password Schema May 2001
[RFC2829] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan
"Authentication Methods for LDAP", RFC 2829, June 2000.
[RFC3062] Zeilenga, K., "LDAP Password Modify Extended Operation",
RFC 3062, February 2001.
[SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
8. Author's
Kurt D.
OpenLDAP
EMail: Kurt@OpenLDAP.
Zeilenga Informational [Page 8]
RFC 3112 LDAP Authentication Password Schema May 2001
9. Full Copyright
Copyright (C) The Internet Society (2001). All Rights Reserved
This document and translations of it may be copied and furnished
others, and derivative works that comment on or otherwise explain
or assist in its implementation may be prepared, copied,
and distributed, in whole or in part, without restriction of
kind, provided that the above copyright notice and this paragraph
included on all such copies and derivative works. However,
document itself may not be modified in any way, such as by
the copyright notice or references to the Internet Society or
Internet organizations, except as needed for the purpose
developing Internet standards in which case the procedures
copyrights defined in the Internet Standards process must
followed, or as required to translate it into languages other
English
The limited permissions granted above are perpetual and will not
revoked by the Internet Society or its successors or assigns
This document and the information contained herein is provided on
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET
TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE
Funding for the RFC Editor function is currently provided by
Internet Society
Zeilenga Informational [Page 9]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
