Authentication Methods for LDAP
RFC 2829
| Document | Type |
RFC - Proposed Standard
(May 2000; No errata)
Updated by RFC 3377
|
|
|---|---|---|---|
| Last updated | 2013-03-02 | ||
| Stream | IETF | ||
| Formats | plain text html pdf htmlized bibtex | ||
| Stream | WG state | (None) | |
| Document shepherd | No shepherd assigned | ||
| IESG | IESG state | RFC 2829 (Proposed Standard) | |
| Consensus Boilerplate | Unknown | ||
| Telechat date | |||
| Responsible AD | (None) | ||
| Send notices to | (None) | ||
Network Working Group M. Wahl
Request for Comments: 2829 Sun Microsystems, Inc.
Category: Standards Track H. Alvestrand
EDB Maxware
J. Hodges
Oblix, Inc.
R. Morgan
University of Washington
May 2000
Authentication Methods for LDAP
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 (2000). All Rights Reserved.
Abstract
This document specifies particular combinations of security
mechanisms which are required and recommended in LDAP [1]
implementations.
1. Introduction
LDAP version 3 is a powerful access protocol for directories.
It offers means of searching, fetching and manipulating directory
content, and ways to access a rich set of security functions.
In order to function for the best of the Internet, it is vital that
these security functions be interoperable; therefore there has to be
a minimum subset of security functions that is common to all
implementations that claim LDAPv3 conformance.
Basic threats to an LDAP directory service include:
(1) Unauthorized access to data via data-fetching operations,
Wahl, et al. Standards Track [Page 1]
RFC 2829 Authentication Methods for LDAP May 2000
(2) Unauthorized access to reusable client authentication
information by monitoring others' access,
(3) Unauthorized access to data by monitoring others' access,
(4) Unauthorized modification of data,
(5) Unauthorized modification of configuration,
(6) Unauthorized or excessive use of resources (denial of
service), and
(7) Spoofing of directory: Tricking a 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 connection.
Threats (1), (4), (5) and (6) are due to hostile clients. Threats
(2), (3) and (7) are due to hostile agents on the path between client
and server, or posing as a server.
The LDAP protocol suite can be protected with the following security
mechanisms:
(1) Client authentication by means of the SASL [2] mechanism
set, possibly backed by the TLS credentials exchange
mechanism,
(2) Client authorization by means of access control based on the
requestor's authenticated identity,
(3) Data integrity protection by means of the TLS protocol or
data-integrity SASL mechanisms,
(4) Protection against snooping by means of the TLS protocol or
data-encrypting SASL mechanisms,
(5) Resource limitation by means of administrative limits on
service controls, and
(6) Server authentication by means of the TLS protocol or SASL
mechanism.
At the moment, imposition of access controls is done by means outside
the scope of the LDAP protocol.
In this document, the term "user" represents any application which is
an LDAP client using the directory to retrieve or store information.
Wahl, et al. Standards Track [Page 2]
RFC 2829 Authentication Methods for LDAP May 2000
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [3].
2. Example deployment scenarios
The following scenarios are typical for LDAP directories on the
Internet, and have different security requirements. (In the
following, "sensitive" means data that will cause real damage to the
owner if revealed; there may be data that is protected but not
sensitive). This is not intended to be a comprehensive list, other
scenarios are possible, especially on physically protected networks.
(1) A read-only directory, containing no sensitive data,
accessible to "anyone", and TCP connection hijacking or IP
spoofing is not a problem. This directory requires no
security functions except administrative service limits.
Show full document text