rfc2829.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

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.

      (2)   A read-only directory containing no sensitive data; read
            access is granted based on identity.  TCP connection
            hijacking is not currently a problem. This scenario requires
            a secure authentication function.

      (3)   A read-only directory containing no sensitive data; and the
            client needs to ensure that the directory data is
            authenticated by the server and not modified while being
            returned from the server.

      (4)   A read-write directory, containing no sensitive data; read
            access is available to "anyone", update access to properly
            authorized persons.  TCP connection hijacking is not
            currently a problem.  This scenario requires a secure
            authentication function.

      (5)   A directory containing sensitive data.  This scenario
            requires session confidentiality protection AND secure
            authentication.

3.  Authentication and Authorization:  Definitions and Concepts

   This section 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.







Wahl, et al.                Standards Track                     [Page 3]

RFC 2829            Authentication Methods for LDAP             May 2000


3.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.  A common expression of an access
   control policy is an access control list.  Security objects and
   mechanisms, such as those described here, enable the expression of
   access control policies and their enforcement.  Access control
   policies are typically expressed in terms of access control
   attributes as described below.

3.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 (section 4.2 of [1]).
   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
   connection via which the request is transmitted, others (e.g. time of
   day) may be "environmental".

   Access control policies are expressed in terms of access control
   factors.  E.g., 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.

3.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 an association 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.  For example: X.509 certificates, Kerberos tickets,
   simple identity and password pairs.  Note that an authentication
   mechanism may constrain the form of authentication identities used
   with it.







Wahl, et al.                Standards Track                     [Page 4]

RFC 2829            Authentication Methods for LDAP             May 2000


3.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; e.g., entity X can perform operation Y
   on resource Z.

   The authorization identity bound to an association is often exactly
   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 [2].  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, 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.

4. Required security mechanisms

   It is clear that allowing any implementation, faced with the above
   requirements, to pick and choose among the possible alternatives is
   not a strategy that is likely to lead to interoperability. In the
   absence of mandates, clients will be written that do not support any
   security function supported by the server, or worse, support only
   mechanisms like cleartext passwords that provide clearly inadequate
   security.

   Active intermediary attacks are the most difficult for an attacker to
   perform, and for an implementation to protect against.  Methods that
   protect only against hostile client and passive eavesdropping attacks
   are useful in situations where the cost of protection against active
   intermediary attacks is not justified based on the perceived risk of
   active intermediary attacks.

   Given the presence of the Directory, there is a strong desire to see
   mechanisms where identities take the form of a Distinguished Name and
   authentication data can be stored in the directory; this means that
   either this data is useless for faking authentication (like the Unix
   "/etc/passwd" file format used to be), or its content is never passed
   across the wire unprotected - that is, it's either updated outside
   the protocol or it is only updated in sessions well protected against
   snooping.  It is also desirable to allow authentication methods to




Wahl, et al.                Standards Track                     [Page 5]

RFC 2829            Authentication Methods for LDAP             May 2000


   carry authorization identities based on existing forms of user
   identities for backwards compatibility with non-LDAP-based
   authentication services.

   Therefore, the following implementation conformance requirements are
   in place:

      (1)   For a read-only, public directory, anonymous authentication,
            described in section 5, can be used.

      (2)   Implementations providing password-based authenticated
            access MUST support authentication using the DIGEST-MD5 SASL
            mechanism [4], as described in section 6.1.  This provides
            client authentication with protection against passive