mirror of
https://git.openldap.org/openldap/openldap.git
synced 2024-12-21 03:10:25 +08:00
502 lines
18 KiB
Plaintext
502 lines
18 KiB
Plaintext
|
INTERNET-DRAFT Kurt D. Zeilenga
|
|||
|
Intended Category: Standard Track OpenLDAP Foundation
|
|||
|
Expires: 11 January 2001 11 July 2000
|
|||
|
|
|||
|
|
|||
|
LDAP Authentication Password Attribute
|
|||
|
<draft-zeilenga-ldap-authpasswd-03.txt>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
1. Status of this Memo
|
|||
|
|
|||
|
This document is an Internet-Draft and is in full conformance with all
|
|||
|
provisions of Section 10 of RFC2026.
|
|||
|
|
|||
|
This document is intended to be, after appropriate review and
|
|||
|
revision, submitted to the RFC Editor as a Standard Track document.
|
|||
|
Distribution of this memo is unlimited. Technical discussion of this
|
|||
|
document will take place on the IETF LDAP Extension Working Group
|
|||
|
mailing list <ietf-ldapext@netscape.com>. Please send editorial
|
|||
|
comments directly to the author <Kurt@OpenLDAP.org>.
|
|||
|
|
|||
|
Internet-Drafts are working documents of the Internet Engineering Task
|
|||
|
Force (IETF), its areas, and its working groups. Note that other
|
|||
|
groups may also distribute working documents as Internet-Drafts.
|
|||
|
Internet-Drafts are draft documents valid for a maximum of six months
|
|||
|
and may be updated, replaced, or obsoleted by other documents at any
|
|||
|
time. It is inappropriate to use Internet-Drafts as reference
|
|||
|
material or to cite them other than as ``work in progress.''
|
|||
|
|
|||
|
The list of current Internet-Drafts can be accessed at
|
|||
|
http://www.ietf.org/ietf/1id-abstracts.txt The list of Internet-Draft
|
|||
|
Shadow Directories can be accessed at http://www.ietf.org/shadow.html.
|
|||
|
|
|||
|
Copyright 2000, The Internet Society. All Rights Reserved.
|
|||
|
|
|||
|
Please see the Copyright section near the end of this document for
|
|||
|
more information.
|
|||
|
|
|||
|
|
|||
|
2. Abstract
|
|||
|
|
|||
|
This document describes schema for storing information in support of
|
|||
|
user/password authentication in a LDAP [RFC2251] directory. The
|
|||
|
document defines the authPassword attribute type and related schema.
|
|||
|
The attribute type is used to store values derived from the user's
|
|||
|
password(s) (commonly using cryptographic strength one-way hash).
|
|||
|
authPassword is intended to used instead of clear text password
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga [Page 1]
|
|||
|
|
|||
|
INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
|
|||
|
|
|||
|
|
|||
|
storage mechanisms such as userPassword [RFC2256]. The values of
|
|||
|
authPassword may be used to support both LDAP "simple" and SASL
|
|||
|
[RFC2222] password authentication mechanisms [RFC2829].
|
|||
|
|
|||
|
The key words ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL
|
|||
|
NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', and ``MAY'' in
|
|||
|
this document are to be interpreted as described in RFC 2119
|
|||
|
[RFC2119].
|
|||
|
|
|||
|
|
|||
|
3. Background and Intended Use
|
|||
|
|
|||
|
The userPassword attribute type [RFC 2256] is intended be used to used
|
|||
|
to support the LDAP [RFC2251] "simple" bind operation. However,
|
|||
|
values of userPassword must be clear text passwords. It is often
|
|||
|
desirable to store values derived from the user's password(s) instead
|
|||
|
of actual passwords.
|
|||
|
|
|||
|
The authPassword attribute type is intended to be used to store
|
|||
|
information used to implement password based authentication. The
|
|||
|
attribute type may be used by LDAP servers to implement user/password
|
|||
|
authentication operations [RFC2829] such "simple" and SASL [RFC2222] /
|
|||
|
DIGEST-MD5 [RFC2831].
|
|||
|
|
|||
|
The attribute type supports multiple storage schemes. A matching rule
|
|||
|
is provided for use with extensible search filters to allow clients to
|
|||
|
assert that a clear text password "matches" one of the attribute's
|
|||
|
values. Storage schemes often use of cryptographic strength one-way
|
|||
|
hashing.
|
|||
|
|
|||
|
This attribute may be used in conjunction with server side password
|
|||
|
generation mechanisms (such as [PW-EXOP]).
|
|||
|
|
|||
|
Access to this attribute may governed by administrative controls such
|
|||
|
as those which implement password change policies.
|
|||
|
|
|||
|
|
|||
|
4. Schema Definitions
|
|||
|
|
|||
|
The following schema definitions are described in terms of LDAPv3
|
|||
|
Attribute Syntax Definitions [RFC2252] with specific syntax detailed
|
|||
|
using Augmented BNF [RFC2234].
|
|||
|
|
|||
|
Editor's Note: object identifiers (OIDs) will be assigned before this
|
|||
|
document is published as an RFC.
|
|||
|
|
|||
|
4.1. authPasswordSyntax
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga [Page 2]
|
|||
|
|
|||
|
INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
|
|||
|
|
|||
|
|
|||
|
( authPasswordSyntaxOID
|
|||
|
DESC 'authentication password syntax' )
|
|||
|
|
|||
|
Values of this syntax are encoded according to the following BNF:
|
|||
|
|
|||
|
authPasswordValue = w scheme s [authInfo] s authValue w
|
|||
|
scheme = <an IA5 string of uppercase letters, numbers,
|
|||
|
and "-", "_", and "/">
|
|||
|
authInfo = schemeSpecificValue
|
|||
|
authValue = schemeSpecfiicValue
|
|||
|
schemeSpecificValue = <an IA5 printable string
|
|||
|
not containing "$" or " ">
|
|||
|
s = w sep w
|
|||
|
w = *sp
|
|||
|
sep = "$" ; an IA5 dollar sign (36)
|
|||
|
sp = " " ; an IA5 space (20)
|
|||
|
|
|||
|
where scheme describes the storage mechanism, authInfo and authValue
|
|||
|
are a scheme specific. The authInfo field is often a base64 encoded
|
|||
|
salt. The authValue field is often a base64 encoded value derived
|
|||
|
from a user's password(s). Values of this attribute are case
|
|||
|
sensitive.
|
|||
|
|
|||
|
This document describes a number of schemes, as well as requirements
|
|||
|
for the scheme naming, in section 5.
|
|||
|
|
|||
|
|
|||
|
4.2. authPasswordMatch
|
|||
|
|
|||
|
( authPasswordMatchOID
|
|||
|
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 matches
|
|||
|
values of authPasswordSyntax using an extensibleMatch filter
|
|||
|
component. Each value is matched per its scheme. The assertion is
|
|||
|
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 publish
|
|||
|
appropriate matchingRuleUse values per [RFC2252], 4.4.
|
|||
|
|
|||
|
Transfer of authPasswordMatch assertion values is strongly discouraged
|
|||
|
where the underlying transport service cannot guarantee
|
|||
|
confidentiality and may result in disclosure of the values to
|
|||
|
unauthorized parties.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga [Page 3]
|
|||
|
|
|||
|
INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
|
|||
|
|
|||
|
|
|||
|
4.3. supportedAuthPasswordSchemes
|
|||
|
|
|||
|
( supportedAuthPasswordSchemesOID
|
|||
|
NAME 'supportedAuthPasswordSchemes'
|
|||
|
DESC 'supported password storage schemes'
|
|||
|
EQUALITY caseExactIA5Match
|
|||
|
SYNTAX 1.3.6.1.4.1.1466.115.121.1.26{32}
|
|||
|
USAGE dSAOperation )
|
|||
|
|
|||
|
The values of this attribute are names of supported authentication
|
|||
|
password schemes which the server supports. The syntax of a scheme
|
|||
|
name is described in section 4.1. This attribute may only be present
|
|||
|
in the root DSE. If the server does not support any mechanisms this
|
|||
|
attribute will not be present.
|
|||
|
|
|||
|
|
|||
|
4.4. authPassword
|
|||
|
|
|||
|
( authPasswordOID NAME 'authPassword'
|
|||
|
SYNTAX authPasswordSyntaxOID )
|
|||
|
|
|||
|
The values of this attribute are representative of the user's
|
|||
|
password(s) and conform to the authPasswordSyntax described in 4.1.
|
|||
|
The values of this attribute may be used for authentication purposes.
|
|||
|
|
|||
|
This attribute type is defined without any built-in matching rules.
|
|||
|
The absence of an EQUALITY matching rules disallows modification of
|
|||
|
individual values.
|
|||
|
|
|||
|
Transfer of authPassword values is strongly discouraged where the
|
|||
|
underlying transport service cannot guarantee confidentiality and may
|
|||
|
result in disclosure of the values to unauthorized parties.
|
|||
|
|
|||
|
|
|||
|
4.5. authPasswordObject
|
|||
|
|
|||
|
( authPasswordObjectOID NAME 'authPasswordObject'
|
|||
|
DESC 'authentication password mix in class'
|
|||
|
MAY 'authPassword' AUXILIARY )
|
|||
|
|
|||
|
Entries of this object class may contain authPassword attribute types.
|
|||
|
|
|||
|
|
|||
|
5. Schemes
|
|||
|
|
|||
|
This section describes the "MD5", "SHA1", and "SASL/DIGEST-MD5".
|
|||
|
Other schemes may be defined by other documents. Schemes starting
|
|||
|
with string "SASL/" indicate association with a SASL mechanism.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga [Page 4]
|
|||
|
|
|||
|
INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
|
|||
|
|
|||
|
|
|||
|
Schemes which are not described by standard track documents SHOULD be
|
|||
|
named with a leading "X-" or, if associated with a SASL mechanism,
|
|||
|
"SASL/X-" to indicate they are a private or implementation specific
|
|||
|
mechanism, or may be named using the dotted-decimal representation
|
|||
|
[RFC2252] of an OID assigned to the mechanism.
|
|||
|
|
|||
|
|
|||
|
5.1. MD5 scheme
|
|||
|
|
|||
|
The MD5 [RFC1321] scheme name is "MD5".
|
|||
|
|
|||
|
The authValue is the base64 encoding of an MD5 digest of the
|
|||
|
concatenation the user password and optional salt. The base64
|
|||
|
encoding of the salt is provided in the authInfo field.
|
|||
|
Implementations of this scheme must support salts up to 128-bit in
|
|||
|
length. Use with a 64-bit or larger salt is RECOMMENDED.
|
|||
|
|
|||
|
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 the
|
|||
|
authValue field would be the base64 encoding of the MD5 digest of
|
|||
|
"marysalt".
|
|||
|
|
|||
|
A match against an asserted password and an attribute value of this
|
|||
|
scheme SHALL be true if and only if the MD5 digest of concatenation of
|
|||
|
the asserted value and the salt is equal to the MD5 digest contained
|
|||
|
in AuthValue. The match SHALL be undefined if the server is unable to
|
|||
|
complete the equality test for any reason. Otherwise the match SHALL
|
|||
|
be false.
|
|||
|
|
|||
|
Values of this scheme SHOULD only be used to implement simple
|
|||
|
user/password authentication.
|
|||
|
|
|||
|
It is RECOMMENDED that values of this scheme be protected as if they
|
|||
|
were clear text passwords.
|
|||
|
|
|||
|
|
|||
|
5.2. SHA1 scheme
|
|||
|
|
|||
|
The SHA1 [SHA1] scheme name is "SHA1".
|
|||
|
|
|||
|
The authValue is the base64 encoding of an SHA1 digest of the
|
|||
|
concatenation the user password and the optional salt. The base64
|
|||
|
encoding of the salt is provided in the authInfo field.
|
|||
|
Implementations of this scheme must support salts up to 128-bit in
|
|||
|
length. Use with a 64-bit or larger salt is RECOMMENDED.
|
|||
|
|
|||
|
Example:
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga [Page 5]
|
|||
|
|
|||
|
INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
|
|||
|
|
|||
|
|
|||
|
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 the
|
|||
|
authValue field would be the base64 encoding of the SHA1 digest of
|
|||
|
"marysalt".
|
|||
|
|
|||
|
A match against an asserted password and an attribute value of this
|
|||
|
scheme SHALL be true if and only if the SHA1 digest of concatenation
|
|||
|
of the asserted value and the salt is equal to the SHA1 digest
|
|||
|
contained in AuthValue. The match SHALL be undefined if the server is
|
|||
|
unable to complete the equality test for any reason. Otherwise the
|
|||
|
match SHALL be false.
|
|||
|
|
|||
|
Values of this scheme SHOULD only be used to implement simple
|
|||
|
user/password authentication.
|
|||
|
|
|||
|
It is RECOMMENDED that values of this scheme be protected as if they
|
|||
|
were clear text passwords.
|
|||
|
|
|||
|
|
|||
|
5.3. DIGEST-MD5 scheme
|
|||
|
|
|||
|
The DIGEST-MD5 scheme name is "SASL/DIGEST-MD5".
|
|||
|
|
|||
|
The authValue is the base64 encoding of
|
|||
|
H( { username-value, ":", realm-value, ":", passwd } )
|
|||
|
|
|||
|
and authInfo is the base64 encoding of
|
|||
|
{ username-value, ":", realm-value }
|
|||
|
|
|||
|
as defined by RFC2831.
|
|||
|
|
|||
|
Example:
|
|||
|
Given a user "joe" within the realm "localhost" who's password is
|
|||
|
"mary", the info field would be the base64 encoding of
|
|||
|
"joe:localhost" and the authValue field would be the base64 encoding
|
|||
|
of the MD5 digest of "joe:localhost:mary".
|
|||
|
|
|||
|
Values of this scheme SHOULD only be used to implement the
|
|||
|
SASL/DIGEST-MD5 as described by the Authentication Methods for LDAP
|
|||
|
[RFC2829]. A simple password assertion against a value of this scheme
|
|||
|
SHALL be considered undefined.
|
|||
|
|
|||
|
Values of this scheme MUST be protected as if it the values were clear
|
|||
|
text passwords per reasons detailed in DIGEST-MD5, Section 3.9,
|
|||
|
"Storing Passwords."
|
|||
|
|
|||
|
|
|||
|
6. Implementation Issues
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga [Page 6]
|
|||
|
|
|||
|
INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
|
|||
|
|
|||
|
|
|||
|
For implementations of this specification:
|
|||
|
|
|||
|
Servers MAY restrict which schemes are used in conjunction with a
|
|||
|
particular authentication process but SHOULD use all values of
|
|||
|
selected schemes. If the asserted password matches any of the
|
|||
|
stored values, the asserted password SHOULD be considered valid.
|
|||
|
Servers MAY use other authentication storage mechanisms, such as
|
|||
|
userPassword or an external password store, in conjunction with
|
|||
|
authPassword to support the authentication process.
|
|||
|
|
|||
|
Servers that support simple bind MUST support the MD5 scheme and
|
|||
|
SHOULD support the SHA1 scheme.
|
|||
|
|
|||
|
Servers SHOULD not publish values of authPassword nor allow
|
|||
|
operations which expose authPassword or AuthPasswordMatch values to
|
|||
|
unless confidentiality protection is in place.
|
|||
|
|
|||
|
Clients SHOULD not initiate operations which provide or request
|
|||
|
values of authPassword or make authPasswordMatch assertions unless
|
|||
|
confidentiality protection is in place.
|
|||
|
|
|||
|
Clients SHOULD not assume that a successful AuthPasswordMatch,
|
|||
|
whether by compare or search, is sufficient to gain directory
|
|||
|
access. The bind operation MUST be used to authentication to the
|
|||
|
directory.
|
|||
|
|
|||
|
|
|||
|
7. Security Considerations
|
|||
|
|
|||
|
This document describes how authentication information may be stored
|
|||
|
in a directory. Authentication information must be adequately
|
|||
|
protected as unintended disclosure will allow attackers to gain
|
|||
|
immediate access to the directory as described by [RFC2829].
|
|||
|
|
|||
|
Values of authPassword SHOULD be protected as if they were clear text
|
|||
|
passwords. When values are transferred, privacy protections, such as
|
|||
|
IPSEC or TLS, SHOULD be in place.
|
|||
|
|
|||
|
Clients SHOULD use strong authentication mechanisms [RFC2829].
|
|||
|
|
|||
|
AuthPasswordMatch matching rule allows applications to test the
|
|||
|
validity of a user password and, hence, may be used to mount a
|
|||
|
dictionary attack. Servers SHOULD take appropriate measures to
|
|||
|
protect the directory from such attacks.
|
|||
|
|
|||
|
Some password schemes may require CPU intensive operations. Servers
|
|||
|
SHOULD take appropriate measures to protect against Denial of Service
|
|||
|
attacks.
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga [Page 7]
|
|||
|
|
|||
|
INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
|
|||
|
|
|||
|
|
|||
|
AuthPassword does not restrict an authentication identity to a single
|
|||
|
password. An attacker who gains write access to this attribute may
|
|||
|
store additional values without disabling the user's true password(s).
|
|||
|
Use of policy aware clients and servers is RECOMMENDED.
|
|||
|
|
|||
|
The level of protection offered against various attacks differ from
|
|||
|
scheme to scheme. It is RECOMMENDED that servers support scheme
|
|||
|
selection as a configuration item. This allows for a scheme to be
|
|||
|
easily disabled if a significant security flaw is discovered.
|
|||
|
|
|||
|
|
|||
|
8. Copyright
|
|||
|
|
|||
|
Copyright 2000, The Internet Society. All Rights Reserved.
|
|||
|
|
|||
|
This document and translations of it may be copied and furnished to
|
|||
|
others, and derivative works that comment on or otherwise explain it
|
|||
|
or assist in its implementation may be prepared, copied, published and
|
|||
|
distributed, in whole or in part, without restriction of any kind,
|
|||
|
provided that the above copyright notice and this paragraph are
|
|||
|
included on all such copies and derivative works. However, this
|
|||
|
document itself may not be modified in any way, such as by removing
|
|||
|
the copyright notice or references to the Internet Society or other
|
|||
|
Internet organizations, except as needed for the purpose of
|
|||
|
developing Internet standards in which case the procedures for
|
|||
|
copyrights defined in the Internet Standards process must be followed,
|
|||
|
or as required to translate it into languages other than English.
|
|||
|
|
|||
|
The limited permissions granted above are perpetual and will not be
|
|||
|
revoked by the Internet Society or its successors or assigns.
|
|||
|
|
|||
|
This document and the information contained herein is provided on an
|
|||
|
"AS IS" basis and THE AUTHORS, THE INTERNET SOCIETY, AND THE INTERNET
|
|||
|
ENGINEERING TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED,
|
|||
|
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
|
|||
|
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
|
|||
|
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
|
|||
|
|
|||
|
|
|||
|
9. Acknowledgment
|
|||
|
|
|||
|
This document borrows from a number of IETF documents and is based
|
|||
|
upon input from the IETF LDAPext working group.
|
|||
|
|
|||
|
|
|||
|
10. Bibliography
|
|||
|
|
|||
|
[RFC1321] R. Rivest, "The MD5 Message-Digest Algorithm", RFC 1321,
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga [Page 8]
|
|||
|
|
|||
|
INTERNET-DRAFT LDAP AuthPasswd 11 July 2000
|
|||
|
|
|||
|
|
|||
|
April 1992
|
|||
|
|
|||
|
[RFC2219] S. Bradner, "Key words for use in RFCs to Indicate
|
|||
|
Requirement Levels", RFC 2119, March 1997.
|
|||
|
|
|||
|
[RFC2222] J. Myers, "Simple Authentication and Security Layer (SASL)",
|
|||
|
RFC 2222, October 1997.
|
|||
|
|
|||
|
[RFC2234] D. Crocker (editor), P. Overell, "Augmented BNF for Syntax
|
|||
|
Specifications: ABNF", RFC 2234, November 1997.
|
|||
|
|
|||
|
[RFC2251] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
|
|||
|
Protocol (v3)", RFC 2251, December 1997.
|
|||
|
|
|||
|
[RFC2252] M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight
|
|||
|
Directory Access Protocol (v3): Attribute Syntax
|
|||
|
Definitions", RFC 2252, December 1997.
|
|||
|
|
|||
|
[RFC2256] M. Wahl, "A Summary of the X.500(96) User Schema for use
|
|||
|
with LDAPv3", RFC 2256, December 1997.
|
|||
|
|
|||
|
[RFC2307] L. Howard, "An Approach for Using LDAP as a Network
|
|||
|
Information Service", RFC 2307, March 1998.
|
|||
|
|
|||
|
[RFC2829] M. Wahl, H. Alvestrand, J. Hodges, RL "Bob" Morgan,
|
|||
|
"Authentication Methods for LDAP", RFC 2829, June 2000.
|
|||
|
|
|||
|
[RFC2831] P. Leach, C. Newman, "Using Digest Authentication as a SASL
|
|||
|
Mechanism", RFC 2831, June 2000.
|
|||
|
|
|||
|
[PW-EXOP] K. Zeilenga, "LDAP Password Modify Extended Operation"
|
|||
|
draft-zeilenga-ldap-passwd-exop-xx.txt, a work in progress.
|
|||
|
|
|||
|
[SHA1] NIST, FIPS PUB 180-1: Secure Hash Standard, April 1995.
|
|||
|
|
|||
|
|
|||
|
11. Author's Address
|
|||
|
|
|||
|
Kurt D. Zeilenga
|
|||
|
OpenLDAP Foundation
|
|||
|
<Kurt@OpenLDAP.org>
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
|
|||
|
Zeilenga [Page 9]
|
|||
|
|