Authentication Methods for LDAP
RFC 2829

Document Type RFC - Proposed Standard (May 2000; No errata)
Obsoleted by RFC 4513, RFC 4510
Updated by RFC 3377
Authors Morgan Rl  , Jeff Hodges  , Harald Alvestrand  , Mark Wahl 
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.


   This document specifies particular combinations of security
   mechanisms which are required and recommended in LDAP [1]

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

      (1)   Client authentication by means of the SASL [2] mechanism
            set, possibly backed by the TLS credentials exchange

      (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

   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",
   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