Request for Comments: 4513 Novell, Inc.
Obsoletes: 2251, 2829, 2830 June 2006
Category: Standards Track
Lightweight Directory Access Protocol (LDAP):
Authentication Methods and Security Mechanisms
Status of This Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2006).
Abstract
This document describes authentication methods and security
mechanisms of the Lightweight Directory Access Protocol (LDAP). This
document details establishment of Transport Layer Security (TLS)
using the StartTLS operation.
This document details the simple Bind authentication method including
anonymous, unauthenticated, and name/password mechanisms and the
Simple Authentication and Security Layer (SASL) Bind authentication
method including the EXTERNAL mechanism.
This document discusses various authentication and authorization
states through which a session to an LDAP server may pass and the
actions that trigger these state changes.
This document, together with other documents in the LDAP Technical
Specification (see Section 1 of the specification’s road map),
obsoletes RFC 2251, RFC 2829, and RFC 2830.
Table of Contents
1. Introduction ....................................................4
1.1. Relationship to Other Documents ............................6
1.2. Conventions ................................................6
2. Implementation Requirements .....................................7
3. StartTLS Operation ..............................................8
3.1. TLS Establishment Procedures ..............................8
3.1.1. StartTLS Request Sequencing .........................8
3.1.2. Client Certificate ..................................9
3.1.3. Server Identity Check ...............................9
3.1.3.1. Comparison of DNS Names ...................10
3.1.3.2. Comparison of IP Addresses ................11
3.1.3.3. Comparison of Other subjectName Types .....11
3.1.4. Discovery of Resultant Security Level ..............11
3.1.5. Refresh of Server Capabilities Information .........11
3.2. Effect of TLS on Authorization State .....................12
3.3. TLS Ciphersuites ..........................................12
4. Authorization State ............................................13
5. Bind Operation .................................................14
5.1. Simple Authentication Method ..............................14
5.1.1. Anonymous Authentication Mechanism of Simple Bind ..14
5.1.2. Unauthenticated Authentication Mechanism of
Simple Bind ........................................14
5.1.3. Name/Password Authentication Mechanism of
Simple Bind ........................................15
5.2. SASL Authentication Method ................................16
5.2.1. SASL Protocol Profile ..............................16
5.2.1.1. SASL Service Name for LDAP ................16
5.2.1.2. SASL Authentication Initiation and
Protocol Exchange .........................16
5.2.1.3. Optional Fields ...........................17
5.2.1.4. Octet Where Negotiated Security
Layers Take Effect ........................18
5.2.1.5. Determination of Supported SASL
Mechanisms ................................18
5.2.1.6. Rules for Using SASL Layers ...............19
5.2.1.7. Support for Multiple Authentications ......19
5.2.1.8. SASL Authorization Identities .............19
5.2.2. SASL Semantics within LDAP .........................20
5.2.3. SASL EXTERNAL Authentication Mechanism .............20
5.2.3.1. Implicit Assertion ........................21
5.2.3.2. Explicit Assertion ........................21
6. Security Considerations ........................................21
6.1. General LDAP Security Considerations ......................21
6.2. StartTLS Security Considerations ..........................22
6.3. Bind Operation Security Considerations ....................23
6.3.1. Unauthenticated Mechanism Security Considerations ..23
6.3.2. Name/Password Mechanism Security Considerations ....23
6.3.3. Password-Related Security Considerations ...........23
6.3.4. Hashed Password Security Considerations ............24
6.4. SASL Security Considerations ..............................24
6.5. Related Security Considerations ...........................25
7. IANA Considerations ............................................25
8. Acknowledgements ...............................................25
9. Normative References ...........................................26
10. Informative References ........................................27
Appendix A. Authentication and Authorization Concepts .............28
A.1. Access Control Policy .....................................28
A.2. Access Control Factors ....................................28
A.3. Authentication, Credentials, Identity .....................28
A.4. Authorization Identity ....................................29
Appendix B. Summary of Changes ....................................29
B.1. Changes Made to RFC 2251 ..................................30
B.1.1. Section 4.2.1 ("Sequencing of the Bind Request") ...30
B.1.2. Section 4.2.2 ("Authentication and Other Security
Services") .........................................30
B.2. Changes Made to RFC 2829 ..................................30
B.2.1. Section 4 ("Required security mechanisms") .........30
B.2.2. Section 5.1 ("Anonymous authentication
procedure") ........................................31
B.2.3. Section 6 ("Password-based authentication") ........31
B.2.4. Section 6.1 ("Digest authentication") ..............31
B.2.5. Section 6.2 ("’simple’ authentication choice under
TLS encryption") ...................................31
B.2.6. Section 6.3 ("Other authentication choices with
TLS") ..............................................31
B.2.7. Section 7.1 ("Certificate-based authentication
with TLS") .........................................31
B.2.8. Section 8 ("Other mechanisms") .....................32
B.2.9. Section 9 ("Authorization Identity") ...............32
B.2.10. Section 10 ("TLS Ciphersuites") ...................32
B.3. Changes Made to RFC 2830 ..................................32
B.3.1. Section 3.6 ("Server Identity Check") ..............32
B.3.2. Section 3.7 ("Refresh of Server Capabilities
Information") ......................................33
B.3.3. Section 5 ("Effects of TLS on a Client’s
Authorization Identity") ...........................33
B.3.4. Section 5.2 ("TLS Connection Closure Effects") .....33
1. Introduction
The Lightweight Directory Access Protocol (LDAP) [RFC4510] is a
powerful protocol for accessing directories. It offers means of
searching, retrieving, and manipulating directory content and ways to
access a rich set of security functions.
It is vital that these security functions be interoperable among all
LDAP clients and servers on the Internet; therefore there has to be a
minimum subset of security functions that is common to all
implementations that claim LDAP conformance.
Basic threats to an LDAP directory service include (but are not
limited to):
(1) Unauthorized access to directory data via data-retrieval
operations.
(2) Unauthorized access to directory data by monitoring access of
others.
(3) Unauthorized access to reusable client authentication information
by monitoring access of others.
(4) Unauthorized modification of directory data.
(5) Unauthorized modification of configuration information.
(6) Denial of Service: Use of resources (commonly in excess) in a
manner intended to deny service to others.
(7) Spoofing: Tricking a user or client into believing that
information came from the directory when in fact it did not,
either by modifying data in transit or misdirecting the client’s
transport connection. Tricking a user or client into sending
privileged information to a hostile entity that appears to be the
directory server but is not. Tricking a directory server into
believing that information came from a particular client when in
fact it came from a hostile entity.
(8) Hijacking: An attacker seizes control of an established protocol
session.
Threats (1), (4), (5), (6), (7), and (8) are active attacks. Threats
(2) and (3) are passive attacks.
Threats (1), (4), (5), and (6) are due to hostile clients. Threats
(2), (3), (7), and (8) are due to hostile agents on the path between
client and server or hostile agents posing as a server, e.g., IP
spoofing.
LDAP offers the following security mechanisms:
(1) Authentication by means of the Bind operation. The Bind
operation provides a simple method that supports anonymous,
unauthenticated, and name/password mechanisms, and the Simple
Authentication and Security Layer (SASL) method, which supports a
wide variety of authentication mechanisms.
(2) Mechanisms to support vendor-specific access control facilities
(LDAP does not offer a standard access control facility).
(3) Data integrity service by means of security layers in Transport
Layer Security (TLS) or SASL mechanisms.
(4) Data confidentiality service by means of security layers in TLS
or SASL mechanisms.
(5) Server resource usage limitation by means of administrative
limits configured on the server.
(6) Server authentication by means of the TLS protocol or SASL
mechanisms.
LDAP may also be protected by means outside the LDAP protocol, e.g.,
with IP layer security [RFC4301].
Experience has shown that simply allowing implementations to pick and
choose the security mechanisms that will be implemented is not a
strategy that leads to interoperability. In the absence of mandates,
clients will continue to be written that do not support any security
function supported by the server, or worse, they will only support
mechanisms that provide inadequate security for most circumstances.
It is desirable to allow clients to authenticate using a variety of
mechanisms including mechanisms where identities are represented as
distinguished names [X.501][RFC4512], in string form [RFC4514], or as
used in different systems (e.g., simple user names [RFC4013]).
Because some authentication mechanisms transmit credentials in plain
text form, and/or do not provide data security services and/or are
subject to passive attacks, it is necessary to ensure secure
interoperability by identifying a mandatory-to-implement mechanism
for establishing transport-layer security services.
The set of security mechanisms provided in LDAP and described in this
document is intended to meet the security needs for a wide range of
deployment scenarios and still provide a high degree of
interoperability among various LDAP implementations and deployments.
1.1. Relationship to Other Documents
This document is an integral part of the LDAP Technical Specification
[RFC4510].
This document, together with [RFC4510], [RFC4511], and [RFC4512],
obsoletes RFC 2251 in its entirety. Sections 4.2.1 (portions) and
4.2.2 of RFC 2251 are obsoleted by this document. Appendix B.1
summarizes the substantive changes made to RFC 2251 by this document.
This document obsoletes RFC 2829 in its entirety. Appendix B.2
summarizes the substantive changes made to RFC 2829 by this document.
Sections 2 and 4 of RFC 2830 are obsoleted by [RFC4511]. The
remainder of RFC 2830 is obsoleted by this document. Appendix B.3
summarizes the substantive changes made to RFC 2830 by this document.
1.2. Conventions
The key words "MUST", "MUST NOT", "SHALL", "SHOULD", "SHOULD NOT",
"MAY", and "OPTIONAL" in this document are to be interpreted as
described in RFC 2119 [RFC2119].
The term "user" represents any human or application entity that is
accessing the directory using a directory client. A directory client
(or client) is also known as a directory user agent (DUA).
The term "transport connection" refers to the underlying transport
services used to carry the protocol exchange, as well as associations
established by these services.
The term "TLS layer" refers to TLS services used in providing
security services, as well as associations established by these
services.
The term "SASL layer" refers to SASL services used in providing
security services, as well as associations established by these
services.
The term "LDAP message layer" refers to the LDAP Message (PDU)
services used in providing directory services, as well as
associations established by these services.
The term "LDAP session" refers to combined services (transport
connection, TLS layer, SASL layer, LDAP message layer) and their
associations.
In general, security terms in this document are used consistently
with the definitions provided in [RFC2828]. In addition, several
terms and concepts relating to security, authentication, and
authorization are presented in Appendix A of this document. While
the formal definition of these terms and concepts is outside the
scope of this document, an understanding of them is prerequisite to
understanding much of the material in this document. Readers who are
unfamiliar with security-related concepts are encouraged to review
Appendix A before reading the remainder of this document.
2. Implementation Requirements
LDAP server implementations MUST support the anonymous authentication
mechanism of the simple Bind method (Section 5.1.1).
LDAP implementations that support any authentication mechanism other
than the anonymous authentication mechanism of the simple Bind method
MUST support the name/password authentication mechanism of the simple
Bind method (Section 5.1.3) and MUST be capable of protecting this
name/password authentication using TLS as established by the StartTLS
operation (Section 3).
Implementations SHOULD disallow the use of the name/password
authentication mechanism by default when suitable data security
services are not in place, and they MAY provide other suitable data
security services for use with this authentication mechanism.
Implementations MAY support additional authentication mechanisms.
Some of these mechanisms are discussed below.
LDAP server implementations SHOULD support client assertion of
authorization identity via the SASL EXTERNAL mechanism (Section
5.2.3).
LDAP server implementations that support no authentication mechanism
other than the anonymous mechanism of the simple bind method SHOULD
support use of TLS as established by the StartTLS operation (Section
3). (Other servers MUST support TLS per the second paragraph of this
section.)
Implementations supporting TLS MUST support the
TLS_RSA_WITH_3DES_EDE_CBC_SHA ciphersuite and SHOULD support the
TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA ciphersuite. Support for the
latter ciphersuite is recommended to encourage interoperability with
implementations conforming to earlier LDAP StartTLS specifications.
3. StartTLS Operation
The Start Transport Layer Security (StartTLS) operation defined in
Section 4.14 of [RFC4511] provides the ability to establish TLS
[RFC4346] in an LDAP session.
The goals of using the TLS protocol with LDAP are to ensure data
confidentiality and integrity, and to optionally provide for
authentication. TLS expressly provides these capabilities, although
the authentication services of TLS are available to LDAP only in
combination with the SASL EXTERNAL authentication method (see Section
5.2.3), and then only if the SASL EXTERNAL implementation chooses to
make use of the TLS credentials.
3.1. TLS Establishment Procedures
This section describes the overall procedures clients and servers
must follow for TLS establishment. These procedures take into
consideration various aspects of the TLS layer including discovery of
resultant security level and assertion of the client’s authorization
identity.
3.1.1. StartTLS Request Sequencing
A client may send the StartTLS extended request at any time after
establishing an LDAP session, except:
- when TLS is currently established on the session,
- when a multi-stage SASL negotiation is in progress on the
session, or
- when there are outstanding responses for operation requests
previously issued on the session.
As described in [RFC4511], Section 4.14.1, a (detected) violation of
any of these requirements results in a return of the operationsError
resultCode.
Client implementers should ensure that they strictly follow these
operation sequencing requirements to prevent interoperability issues.
Operational experience has shown that violating these requirements
causes interoperability issues because there are race conditions that
prevent servers from detecting some violations of these requirements
due to factors such as server hardware speed and network latencies.
There is no general requirement that the client have or have not
already performed a Bind operation (Section 5) before sending a
StartTLS operation request; however, where a client intends to
perform both a Bind operation and a StartTLS operation, it SHOULD
first perform the StartTLS operation so that the Bind request and
response messages are protected by the data security services
established by the StartTLS operation.
3.1.2. Client Certificate
If an LDAP server requests or demands that a client provide a user
certificate during TLS negotiation and the client does not present a
suitable user certificate (e.g., one that can be validated), the
server may use a local security policy to determine whether to
successfully complete TLS negotiation.
If a client that has provided a suitable certificate subsequently
performs a Bind operation using the SASL EXTERNAL authentication
mechanism (Section 5.2.3), information in the certificate may be used
by the server to identify and authenticate the client.
3.1.3. Server Identity Check
In order to prevent man-in-the-middle attacks, the client MUST verify
the server’s identity (as presented in the server’s Certificate
message). In this section, the client’s understanding of the
server’s identity (typically the identity used to establish the
transport connection) is called the "reference identity".
The client determines the type (e.g., DNS name or IP address) of the
reference identity and performs a comparison between the reference
identity and each subjectAltName value of the corresponding type
until a match is produced. Once a match is produced, the server’s
identity has been verified, and the server identity check is
complete. Different subjectAltName types are matched in different
ways. Sections 3.1.3.1 - 3.1.3.3 explain how to compare values of
various subjectAltName types.
The client may map the reference identity to a different type prior
to performing a comparison. Mappings may be performed for all
available subjectAltName types to which the reference identity can be
mapped; however, the reference identity should only be mapped to
types for which the mapping is either inherently secure (e.g.,
extracting the DNS name from a URI to compare with a subjectAltName
of type dNSName) or for which the mapping is performed in a secure
manner (e.g., using DNSSEC, or using user- or admin-configured host-
to-address/address-to-host lookup tables).
The server’s identity may also be verified by comparing the reference
identity to the Common Name (CN) [RFC4519] value in the leaf Relative
Distinguished Name (RDN) of the subjectName field of the server’s
certificate. This comparison is performed using the rules for
comparison of DNS names in Section 3.1.3.1, below, with the exception
that no wildcard matching is allowed. Although the use of the Common
Name value is existing practice, it is deprecated, and Certification
Authorities are encouraged to provide subjectAltName values instead.
Note that the TLS implementation may represent DNs in certificates
according to X.500 or other conventions. For example, some X.500
implementations order the RDNs in a DN using a left-to-right (most
significant to least significant) convention instead of LDAP’s
right-to-left convention.
If the server identity check fails, user-oriented clients SHOULD
either notify the user (clients may give the user the opportunity to
continue with the LDAP session in this case) or close the transport
connection and indicate that the server’s identity is suspect.
Automated clients SHOULD close the transport connection and then
return or log an error indicating that the server’s identity is
suspect or both.
Beyond the server identity check described in this section, clients
should be prepared to do further checking to ensure that the server
is authorized to provide the service it is requested to provide. The
client may need to make use of local policy information in making
this determination.
3.1.3.1. Comparison of DNS Names
If the reference identity is an internationalized domain name,
conforming implementations MUST convert it to the ASCII Compatible
Encoding (ACE) format as specified in Section 4 of RFC 3490 [RFC3490]
before comparison with subjectAltName values of type dNSName.
Specifically, conforming implementations MUST perform the conversion
operation specified in Section 4 of RFC 3490 as follows:
* in step 1, the domain name SHALL be considered a "stored
string";
* in step 3, set the flag called "UseSTD3ASCIIRules";
* in step 4, process each label with the "ToASCII" operation; and
* in step 5, change all label separators to U+002E (full stop).
After performing the "to-ASCII" conversion, the DNS labels and names
MUST be compared for equality according to the rules specified in
Section 3 of RFC3490.
The ’*’ (ASCII 42) wildcard character is allowed in subjectAltName
values of type dNSName, and then only as the left-most (least
significant) DNS label in that value. This wildcard matches any
left-most DNS label in the server name. That is, the subject
*.example.com matches the server names a.example.com and
b.example.com, but does not match example.com or a.b.example.com.
3.1.3.2. Comparison of IP Addresses
When the reference identity is an IP address, the identity MUST be
converted to the "network byte order" octet string representation
[RFC791][RFC2460]. For IP Version 4, as specified in RFC 791, the
octet string will contain exactly four octets. For IP Version 6, as
specified in RFC 2460, the octet string will contain exactly sixteen
octets. This octet string is then compared against subjectAltName
values of type iPAddress. A match occurs if the reference identity
octet string and value octet strings are identical.
3.1.3.3. Comparison of Other subjectName Types
Client implementations MAY support matching against subjectAltName
values of other types as described in other documents.
3.1.4. Discovery of Resultant Security Level
After a TLS layer is established in an LDAP session, both parties are
to each independently decide whether or not to continue based on
local policy and the security level achieved. If either party
decides that the security level is inadequate for it to continue, it
SHOULD remove the TLS layer immediately after the TLS (re)negotiation