Authentication Methods for LDAP
RFC 2829
Document | Type |
RFC - Proposed Standard
(May 2000; No errata)
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. 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