to determine whether to successfully complete TLS negotiation.
Information in the user’s certificate that is originated or verified
by the certification authority should be used by the policy
administrator when configuring the identification and authorization
policy.
Server implementers SHOULD allow server administrators to elect
whether and when data confidentiality and integrity are required, as
well as elect whether authentication of the client during the TLS
handshake is required.
Implementers should be aware of and understand TLS security
considerations as discussed in the TLS specification [RFC4346].
6.3. Bind Operation Security Considerations
This section discusses several security considerations relevant to
LDAP authentication via the Bind operation.
6.3.1. Unauthenticated Mechanism Security Considerations
Operational experience shows that clients can (and frequently do)
misuse the unauthenticated authentication mechanism of the simple
Bind method (see Section 5.1.2). For example, a client program might
make a decision to grant access to non-directory information on the
basis of successfully completing a Bind operation. LDAP server
implementations may return a success response to an unauthenticated
Bind request. This may erroneously leave the client with the
impression that the server has successfully authenticated the
identity represented by the distinguished name when in reality, an
anonymous authorization state has been established. Clients that use
the results from a simple Bind operation to make authorization
decisions should actively detect unauthenticated Bind requests (by
verifying that the supplied password is not empty) and react
appropriately.
6.3.2. Name/Password Mechanism Security Considerations
The name/password authentication mechanism of the simple Bind method
discloses the password to the server, which is an inherent security
risk. There are other mechanisms, such as SASL DIGEST-MD5
[DIGEST-MD5], that do not disclose the password to the server.
6.3.3. Password-Related Security Considerations
LDAP allows multi-valued password attributes. In systems where
entries are expected to have one and only one password,
administrative controls should be provided to enforce this behavior.
The use of clear text passwords and other unprotected authentication
credentials is strongly discouraged over open networks when the
underlying transport service cannot guarantee confidentiality. LDAP
implementations SHOULD NOT by default support authentication methods
using clear text passwords and other unprotected authentication
credentials unless the data on the session is protected using TLS or
other data confidentiality and data integrity protection.
The transmission of passwords in the clear -- typically for
authentication or modification -- poses a significant security risk.
This risk can be avoided by using SASL authentication [RFC4422]
mechanisms that do not transmit passwords in the clear or by
negotiating transport or session layer data confidentiality services
before transmitting password values.
To mitigate the security risks associated with the transfer of
passwords, a server implementation that supports any password-based
authentication mechanism that transmits passwords in the clear MUST
support a policy mechanism that at the time of authentication or
password modification, requires that:
A TLS layer has been successfully installed.
OR
Some other data confidentiality mechanism that protects the
password value from eavesdropping has been provided.
OR
The server returns a resultCode of confidentialityRequired for
the operation (i.e., name/password Bind with password value,
SASL Bind transmitting a password value in the clear, add or
modify including a userPassword value, etc.), even if the
password value is correct.
Server implementations may also want to provide policy mechanisms to
invalidate or otherwise protect accounts in situations where a server
detects that a password for an account has been transmitted in the
clear.
6.3.4. Hashed Password Security Considerations
Some authentication mechanisms (e.g., DIGEST-MD5) transmit a hash of
the password value that may be vulnerable to offline dictionary
attacks. Implementers should take care to protect such hashed
password values during transmission using TLS or other
confidentiality mechanisms.
6.4. SASL Security Considerations
Until data integrity service is installed on an LDAP session, an
attacker can modify the transmitted values of the
’supportedSASLMechanisms’ attribute response and thus downgrade the
list of available SASL mechanisms to include only the least secure
mechanism. To detect this type of attack, the client may retrieve
the SASL mechanisms the server makes available both before and after
data integrity service is installed on an LDAP session. If the
client finds that the integrity-protected list (the list obtained
after data integrity service was installed) contains a stronger
mechanism than those in the previously obtained list, the client
should assume the previously obtained list was modified by an
attacker. In this circumstance it is recommended that the client
close the underlying transport connection and then reconnect to
reestablish the session.
6.5. Related Security Considerations
Additional security considerations relating to the various
authentication methods and mechanisms discussed in this document
apply and can be found in [RFC4422], [RFC4013], [RFC3454], and
[RFC3629].
7. IANA Considerations
The IANA has updated the LDAP Protocol Mechanism registry to indicate
that this document and [RFC4511] provide the definitive technical
specification for the StartTLS (1.3.6.1.4.1.1466.20037) extended
operation.
The IANA has updated the LDAP LDAPMessage types registry to indicate
that this document and [RFC4511] provide the definitive technical
specification for the bindRequest (0) and bindResponse (1) message
types.
The IANA has updated the LDAP Bind Authentication Method registry to
indicate that this document and [RFC4511] provide the definitive
technical specification for the simple (0) and sasl (3) bind
authentication methods.
The IANA has updated the LDAP authzid prefixes registry to indicate
that this document provides the definitive technical specification
for the dnAuthzId (dn:) and uAuthzId (u:) authzid prefixes.
8. Acknowledgements
This document combines information originally contained in RFC 2251,
RFC 2829, and RFC 2830. RFC 2251 was a product of the Access,
Searching, and Indexing of Directories (ASID) Working Group. RFC
2829 and RFC 2830 were products of the LDAP Extensions (LDAPEXT)
Working Group.
This document is a product of the IETF LDAP Revision (LDAPBIS)
working group.
9. Normative References
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791,
September 1981.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
(IPv6) Specification", RFC 2460, December 1998.
[RFC3454] Hoffman, P. and M. Blanchet, "Preparation of
Internationalized Strings ("stringprep")", RFC 3454,
December 2002.
[RFC3490] Faltstrom, P., Hoffman, P., and A. Costello,
"Internationalizing Domain Names in Applications
(IDNA)", RFC 3490, March 2003.
[RFC3629] Yergeau, F., "UTF-8, a transformation format of ISO
10646", STD 63, RFC 3629, November 2003.
[RFC4013] Zeilenga, K., "SASLprep: Stringprep Profile for User
Names and Passwords", RFC 4013, February 2005.
[RFC4234] Crocker, D. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", RFC 4234, October 2005.
[RFC4346] Dierks, T. and E. Rescorla, "The TLS Protocol Version
1.1", RFC 4346, March 2006.
[RFC4422] Melnikov, A., Ed. and K. Zeilenga, Ed., "Simple
Authentication and Security Layer (SASL)", RFC 4422,
June 2006.
[RFC4510] Zeilenga, K., Ed., "Lightweight Directory Access
Protocol (LDAP): Technical Specification Road Map", RFC
4510, June 2006.
[RFC4511] Sermersheim, J., Ed., "Lightweight Directory Access
Protocol (LDAP): The Protocol", RFC 4511, June 2006.
[RFC4512] Zeilenga, K., "Lightweight Directory Access Protocol
(LDAP): Directory Information Models", RFC 4512, June
2006.
[RFC4514] Zeilenga, K., Ed., "Lightweight Directory Access
Protocol (LDAP): String Representation of Distinguished
Names", RFC 4514, June 2006.
[RFC4517] Legg, S., Ed., "Lightweight Directory Access Protocol
(LDAP): Syntaxes and Matching Rules", RFC 4517, June
2006.
[RFC4519] Sciberras, A., Ed., "Lightweight Directory Access
Protocol (LDAP): Schema for User Applications", RFC
4519, June 2006.
[RFC4520] Zeilenga, K., "Internet Assigned Numbers Authority
(IANA) Considerations for the Lightweight Directory
Access Protocol (LDAP)", BCP 64, RFC 4520, June 2006.
[Unicode] The Unicode Consortium, "The Unicode Standard, Version
3.2.0" is defined by "The Unicode Standard, Version 3.0"
(Reading, MA, Addison-Wesley, 2000. ISBN 0-201-61633-
5), as amended by the "Unicode Standard Annex #27:
Unicode 3.1" (http://www.unicode.org/reports/tr27/) and
by the "Unicode Standard Annex #28: Unicode 3.2"
(http://www.unicode.org/reports/tr28/).
[X.501] ITU-T Rec. X.501, "The Directory: Models", 1993.
10. Informative References
[DIGEST-MD5] Leach, P., Newman, C., and A. Melnikov, "Using Digest
Authentication as a SASL Mechanism", Work in Progress,
March 2006.
[PLAIN] Zeilenga, K., "The Plain SASL Mechanism", Work in
Progress, March 2005.
[RFC2828] Shirey, R., "Internet Security Glossary", FYI 36, RFC
2828, May 2000.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the
Internet Protocol", RFC 4301, December 2005.
[RFC4505] Zeilenga, K., "The Anonymous SASL Mechanism", RFC 4505,
June 2006.
Appendix A. Authentication and Authorization Concepts
This appendix is non-normative.
This appendix defines basic terms, concepts, and interrelationships
regarding authentication, authorization, credentials, and identity.
These concepts are used in describing how various security approaches
are utilized in client authentication and authorization.
A.1. Access Control Policy
An access control policy is a set of rules defining the protection of
resources, generally in terms of the capabilities of persons or other
entities accessing those resources. Security objects and mechanisms,
such as those described here, enable the expression of access control
policies and their enforcement.
A.2. Access Control Factors
A request, when it is being processed by a server, may be associated
with a wide variety of security-related factors. The server uses
these factors to determine whether and how to process the request.
These are called access control factors (ACFs). They might include
source IP address, encryption strength, the type of operation being
requested, time of day, etc.. Some factors may be specific to the
request itself; others may be associated with the transport
connection via which the request is transmitted; and others (e.g.,
time of day) may be "environmental".
Access control policies are expressed in terms of access control
factors; for example, "a request having ACFs i,j,k can perform
operation Y on resource Z". The set of ACFs that a server makes
available for such expressions is implementation specific.
A.3. Authentication, Credentials, Identity
Authentication credentials are the evidence supplied by one party to
another, asserting the identity of the supplying party (e.g., a user)
who is attempting to establish a new authorization state with the
other party (typically a server). Authentication is the process of
generating, transmitting, and verifying these credentials and thus
the identity they assert. An authentication identity is the name
presented in a credential.
There are many forms of authentication credentials. The form used
depends upon the particular authentication mechanism negotiated by
the parties. X.509 certificates, Kerberos tickets, and simple
identity and password pairs are all examples of authentication
credential forms. Note that an authentication mechanism may
constrain the form of authentication identities used with it.
A.4. Authorization Identity
An authorization identity is one kind of access control factor. It
is the name of the user or other entity that requests that operations
be performed. Access control policies are often expressed in terms
of authorization identities; for example, "entity X can perform
operation Y on resource Z".
The authorization identity of an LDAP session is often semantically
the same as the authentication identity presented by the client, but
it may be different. SASL allows clients to specify an authorization
identity distinct from the authentication identity asserted by the
client’s credentials. This permits agents such as proxy servers to
authenticate using their own credentials, yet request the access
privileges of the identity for which they are proxying [RFC4422].
Also, the form of authentication identity supplied by a service like
TLS may not correspond to the authorization identities used to
express a server’s access control policy, thus requiring a server-
specific mapping to be done. The method by which a server composes
and validates an authorization identity from the authentication
credentials supplied by a client is implementation specific.
Appendix B. Summary of Changes
This appendix is non-normative.
This appendix summarizes substantive changes made to RFC 2251, RFC
2829 and RFC 2830. In addition to the specific changes detailed
below, the reader of this document should be aware that numerous
general editorial changes have been made to the original content from
the source documents. These changes include the following:
- The material originally found in RFC 2251 Sections 4.2.1 and 4.2.2,
RFC 2829 (all sections except Sections 2 and 4), and RFC 2830 was
combined into a single document.
- The combined material was substantially reorganized and edited to
group related subjects, improve the document flow, and clarify
intent.
- Changes were made throughout the text to align with definitions of
LDAP protocol layers and IETF security terminology.
- Substantial updates and additions were made to security
considerations from both documents based on current operational
experience.
B.1. Changes Made to RFC 2251
This section summarizes the substantive changes made to Sections
4.2.1 and 4.2.2 of RFC 2251 by this document. Additional substantive
changes to Section 4.2.1 of RFC 2251 are also documented in
[RFC4511].
B.1.1. Section 4.2.1 ("Sequencing of the Bind Request")
- Paragraph 1: Removed the sentence, "If at any stage the client
wishes to abort the bind process it MAY unbind and then drop the
underlying connection". The Unbind operation still permits this
behavior, but it is not documented explicitly.
- Clarified that the session is moved to an anonymous state upon
receipt of the BindRequest PDU and that it is only moved to a non-
anonymous state if and when the Bind request is successful.
B.1.2. Section 4.2.2 ("Authentication and Other Security Services")
- RFC 2251 states that anonymous authentication MUST be performed
using the simple bind method. This specification defines the
anonymous authentication mechanism of the simple bind method and
requires all conforming implementations to support it. Other
authentication mechanisms producing anonymous authentication and
authorization state may also be implemented and used by conforming
implementations.
B.2. Changes Made to RFC 2829
This section summarizes the substantive changes made to RFC 2829.
B.2.1. Section 4 ("Required security mechanisms")
- The name/password authentication mechanism (see Section B.2.5
below) protected by TLS replaces the SASL DIGEST-MD5 mechanism as
LDAP’s mandatory-to-implement password-based authentication
mechanism. Implementations are encouraged to continue supporting
SASL DIGEST-MD5 [DIGEST-MD5].
B.2.2. Section 5.1 ("Anonymous authentication procedure")
- Clarified that anonymous authentication involves a name value of
zero length and a password value of zero length. The
unauthenticated authentication mechanism was added to handle simple
Bind requests involving a name value with a non-zero length and a
password value of zero length.
B.2.3. Section 6 ("Password-based authentication")
- See Section B.2.1.
B.2.4. Section 6.1 ("Digest authentication")
- As the SASL-DIGEST-MD5 mechanism is no longer mandatory to
implement, this section is now historical and was not included in
this document. RFC 2829, Section 6.1, continues to document the
SASL DIGEST-MD5 authentication mechanism.
B.2.5. Section 6.2 ("’simple’ authentication choice under TLS
encryption")
- Renamed the "simple" authentication mechanism to the name/password
authentication mechanism to better describe it.
- The use of TLS was generalized to align with definitions of LDAP
protocol layers. TLS establishment is now discussed as an
independent subject and is generalized for use with all
authentication mechanisms and other security layers.
- Removed the implication that the userPassword attribute is the sole
location for storage of password values to be used in
authentication. There is no longer any implied requirement for how
or where passwords are stored at the server for use in
authentication.
B.2.6. Section 6.3 ("Other authentication choices with TLS")
- See Section B.2.5.
B.2.7. Section 7.1 ("Certificate-based authentication with TLS")
- See Section B.2.5.
B.2.8. Section 8 ("Other mechanisms")
- All SASL authentication mechanisms are explicitly allowed within
LDAP. Specifically, this means the SASL ANONYMOUS and SASL PLAIN
mechanisms are no longer precluded from use within LDAP.
B.2.9. Section 9 ("Authorization Identity")
- Specified matching rules for dnAuthzId and uAuthzId values. In
particular, the DN value in the dnAuthzId form must be matched
using DN matching rules, and the uAuthzId value MUST be prepared
using SASLprep rules before being compared octet-wise.
- Clarified that uAuthzId values should not be assumed to be globally
unique.
B.2.10. Section 10 ("TLS Ciphersuites")
- TLS ciphersuite recommendations are no longer included in this
specification. Implementations must now support the
TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and should continue to
support the TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite.
- Clarified that anonymous authentication involves a name value of
zero length and a password value of zero length. The
unauthenticated authentication mechanism was added to handle simple
Bind requests involving a name value with a non-zero length and a
password value of zero length.
B.3. Changes Made to RFC 2830
This section summarizes the substantive changes made to Sections 3
and 5 of RFC 2830. Readers should consult [RFC4511] for summaries of
changes to other sections.
B.3.1. Section 3.6 ("Server Identity Check")
- Substantially updated the server identity check algorithm to ensure
that it is complete and robust. In particular, the use of all
relevant values in the subjectAltName and the subjectName fields
are covered by the algorithm and matching rules are specified for
each type of value. Mapped (derived) forms of the server identity
may now be used when the mapping is performed in a secure fashion.
B.3.2. Section 3.7 ("Refresh of Server Capabilities Information")
- Clients are no longer required to always refresh information about
server capabilities following TLS establishment. This is to allow
for situations where this information was obtained through a secure
mechanism.
B.3.3. Section 5 ("Effects of TLS on a Client’s Authorization
Identity")
- Establishing a TLS layer on an LDAP session may now cause the
authorization state of the LDAP session to change.
B.3.4. Section 5.2 ("TLS Connection Closure Effects")
- Closing a TLS layer on an LDAP session changes the authentication
and authorization state of the LDAP session based on local policy.
Specifically, this means that implementations are not required to
change the authentication and authorization states to anonymous
upon TLS closure.
- Replaced references to RFC 2401 with RFC 4301.
Author’s Address
Roger Harrison
Novell, Inc.
1800 S. Novell Place
Provo, UT 84606
USA
Phone: +1 801 861 2642
EMail: roger_harrison@novell.com
Full Copyright Statement
Copyright (C) The Internet Society (2006).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM 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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at
ietf-ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is provided by the IETF
Administrative Support Activity (IASA).