You are viewing a plain text version of this content. The canonical link for it is here.
Posted to commits@directory.apache.org by se...@apache.org on 2018/09/09 15:55:44 UTC
svn commit: r1034904 [10/35] - in
/websites/production/directory/content/studio/users-guide/2.0.0.v20180908-M14:
./ apache_directory_studio/ apache_directory_studio/css/
apache_directory_studio/images/ apacheds/ apacheds/css/ apacheds/images/
apacheds/...
Added: websites/production/directory/content/studio/users-guide/2.0.0.v20180908-M14/ldap_browser/rfc/rfc2829.txt
==============================================================================
--- websites/production/directory/content/studio/users-guide/2.0.0.v20180908-M14/ldap_browser/rfc/rfc2829.txt (added)
+++ websites/production/directory/content/studio/users-guide/2.0.0.v20180908-M14/ldap_browser/rfc/rfc2829.txt Sun Sep 9 15:55:38 2018
@@ -0,0 +1,899 @@
+
+
+
+
+
+
+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
+ eavesdropping attacks, but does not provide protection
+ against active intermediary attacks.
+
+ (3) For a directory needing session protection and
+ authentication, the Start TLS extended operation [5], and
+ either the simple authentication choice or the SASL EXTERNAL
+ mechanism, are to be used together. Implementations SHOULD
+ support authentication with a password as described in
+ section 6.2, and SHOULD support authentication with a
+ certificate as described in section 7.1. Together, these
+ can provide integrity and disclosure protection of
+ transmitted data, and authentication of client and server,
+ including protection against active intermediary attacks.
+
+ If TLS is negotiated, the client MUST discard all information about
+ the server fetched prior to the TLS negotiation. In particular, the
+ value of supportedSASLMechanisms MAY be different after TLS has been
+ negotiated (specifically, the EXTERNAL mechanism or the proposed
+ PLAIN mechanism are likely to only be listed after a TLS negotiation
+ has been performed).
+
+ If a SASL security layer is negotiated, the client MUST discard all
+ information about the server fetched prior to SASL. In particular,
+ if the client is configured to support multiple SASL mechanisms, it
+ SHOULD fetch supportedSASLMechanisms both before and after the SASL
+ security layer is negotiated and verify that the value has not
+ changed after the SASL security layer was negotiated. This detects
+ active attacks which remove supported SASL mechanisms from the
+ supportedSASLMechanisms list, and allows the client to ensure that it
+ is using the best mechanism supported by both client and server
+ (additionally, this is a SHOULD to allow for environments where the
+ supported SASL mechanisms list is provided to the client through a
+ different trusted source, e.g. as part of a digitally signed object).
+
+
+
+
+Wahl, et al. Standards Track [Page 6]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+5. Anonymous authentication
+
+ Directory operations which modify entries or access protected
+ attributes or entries generally require client authentication.
+ Clients which do not intend to perform any of these operations
+ typically use anonymous authentication.
+
+ LDAP implementations MUST support anonymous authentication, as
+ defined in section 5.1.
+
+ LDAP implementations MAY support anonymous authentication with TLS,
+ as defined in section 5.2.
+
+ While there MAY be access control restrictions to prevent access to
+ directory entries, an LDAP server SHOULD allow an anonymously-bound
+ client to retrieve the supportedSASLMechanisms attribute of the root
+ DSE.
+
+ An LDAP server MAY use other information about the client provided by
+ the lower layers or external means to grant or deny access even to
+ anonymously authenticated clients.
+
+5.1. Anonymous authentication procedure
+
+ An LDAP client which has not successfully completed a bind operation
+ on a connection is anonymously authenticated.
+
+ An LDAP client MAY also specify anonymous authentication in a bind
+ request by using a zero-length OCTET STRING with the simple
+ authentication choice.
+
+5.2. Anonymous authentication and TLS
+
+ An LDAP client MAY use the Start TLS operation [5] to negotiate the
+ use of TLS security [6]. If the client has not bound beforehand,
+ then until the client uses the EXTERNAL SASL mechanism to negotiate
+ the recognition of the client's certificate, the client is
+ anonymously authenticated.
+
+ Recommendations on TLS ciphersuites are given in section 10.
+
+ An LDAP server which requests that clients provide their certificate
+ during TLS negotiation MAY use a local security policy to determine
+ whether to successfully complete TLS negotiation if the client did
+ not present a certificate which could be validated.
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 7]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+6. Password-based authentication
+
+ LDAP implementations MUST support authentication with a password
+ using the DIGEST-MD5 SASL mechanism for password protection, as
+ defined in section 6.1.
+
+ LDAP implementations SHOULD support authentication with the "simple"
+ password choice when the connection is protected against
+ eavesdropping using TLS, as defined in section 6.2.
+
+6.1. Digest authentication
+
+ An LDAP client MAY determine whether the server supports this
+ mechanism by performing a search request on the root DSE, requesting
+ the supportedSASLMechanisms attribute, and checking whether the
+ string "DIGEST-MD5" is present as a value of this attribute.
+
+ In the first stage of authentication, when the client is performing
+ an "initial authentication" as defined in section 2.1 of [4], the
+ client sends a bind request in which the version number is 3, the
+ authentication choice is sasl, the sasl mechanism name is "DIGEST-
+ MD5", and the credentials are absent. The client then waits for a
+ response from the server to this request.
+
+ The server will respond with a bind response in which the resultCode
+ is saslBindInProgress, and the serverSaslCreds field is present. The
+ contents of this field is a string defined by "digest-challenge" in
+ section 2.1.1 of [4]. The server SHOULD include a realm indication
+ and MUST indicate support for UTF-8.
+
+ The client will send a bind request with a distinct message id, in
+ which the version number is 3, the authentication choice is sasl, the
+ sasl mechanism name is "DIGEST-MD5", and the credentials contain the
+ string defined by "digest-response" in section 2.1.2 of [4]. The
+ serv-type is "ldap".
+
+ The server will respond with a bind response in which the resultCode
+ is either success, or an error indication. If the authentication is
+ successful and the server does not support subsequent authentication,
+ then the credentials field is absent. If the authentication is
+ successful and the server supports subsequent authentication, then
+ the credentials field contains the string defined by "response-auth"
+ in section 2.1.3 of [4]. Support for subsequent authentication is
+ OPTIONAL in clients and servers.
+
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 8]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+6.2. "simple" authentication choice under TLS encryption
+
+ A user who has a directory entry containing a userPassword attribute
+ MAY authenticate to the directory by performing a simple password
+ bind sequence following the negotiation of a TLS ciphersuite
+ providing connection confidentiality [6].
+
+ The client will use the Start TLS operation [5] to negotiate the use
+ of TLS security [6] on the connection to the LDAP server. The client
+ need not have bound to the directory beforehand.
+
+ For this authentication procedure to be successful, the client and
+ server MUST negotiate a ciphersuite which contains a bulk encryption
+ algorithm of appropriate strength. Recommendations on cipher suites
+ are given in section 10.
+
+ Following the successful completion of TLS negotiation, the client
+ MUST send an LDAP bind request with the version number of 3, the name
+ field containing the name of the user's entry, and the "simple"
+ authentication choice, containing a password.
+
+ The server will, for each value of the userPassword attribute in the
+ named user's entry, compare these for case-sensitive equality with
+ the client's presented password. If there is a match, then the
+ server will respond with resultCode success, otherwise the server
+ will respond with resultCode invalidCredentials.
+
+6.3. Other authentication choices with TLS
+
+ It is also possible, following the negotiation of TLS, to perform a
+ SASL authentication which does not involve the exchange of plaintext
+ reusable passwords. In this case the client and server need not
+ negotiate a ciphersuite which provides confidentiality if the only
+ service required is data integrity.
+
+7. Certificate-based authentication
+
+ LDAP implementations SHOULD support authentication via a client
+ certificate in TLS, as defined in section 7.1.
+
+7.1. Certificate-based authentication with TLS
+
+ A user who has a public/private key pair in which the public key has
+ been signed by a Certification Authority may use this key pair to
+ authenticate to the directory server if the user's certificate is
+ requested by the server. The user's certificate subject field SHOULD
+ be the name of the user's directory entry, and the Certification
+ Authority must be sufficiently trusted by the directory server to
+
+
+
+Wahl, et al. Standards Track [Page 9]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+ have issued the certificate in order that the server can process the
+ certificate. The means by which servers validate certificate paths
+ is outside the scope of this document.
+
+ A server MAY support mappings for certificates in which the subject
+ field name is different from the name of the user's directory entry.
+ A server which supports mappings of names MUST be capable of being
+ configured to support certificates for which no mapping is required.
+
+ The client will use the Start TLS operation [5] to negotiate the use
+ of TLS security [6] on the connection to the LDAP server. The client
+ need not have bound to the directory beforehand.
+
+ In the TLS negotiation, the server MUST request a certificate. The
+ client will provide its certificate to the server, and MUST perform a
+ private key-based encryption, proving it has the private key
+ associated with the certificate.
+
+ As deployments will require protection of sensitive data in transit,
+ the client and server MUST negotiate a ciphersuite which contains a
+ bulk encryption algorithm of appropriate strength. Recommendations
+ of cipher suites are given in section 10.
+
+ The server MUST verify that the client's certificate is valid. The
+ server will normally check that the certificate is issued by a known
+ CA, and that none of the certificates on the client's certificate
+ chain are invalid or revoked. There are several procedures by which
+ the server can perform these checks.
+
+ Following the successful completion of TLS negotiation, the client
+ will send an LDAP bind request with the SASL "EXTERNAL" mechanism.
+
+8. Other mechanisms
+
+ The LDAP "simple" authentication choice is not suitable for
+ authentication on the Internet where there is no network or transport
+ layer confidentiality.
+
+ As LDAP includes native anonymous and plaintext authentication
+ methods, the "ANONYMOUS" and "PLAIN" SASL mechanisms are not used
+ with LDAP. If an authorization identity of a form different from a
+ DN is requested by the client, a mechanism that protects the password
+ in transit SHOULD be used.
+
+ The following SASL-based mechanisms are not considered in this
+ document: KERBEROS_V4, GSSAPI and SKEY.
+
+
+
+
+
+Wahl, et al. Standards Track [Page 10]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+ The "EXTERNAL" SASL mechanism can be used to request the LDAP server
+ make use of security credentials exchanged by a lower layer. If a TLS
+ session has not been established between the client and server prior
+ to making the SASL EXTERNAL Bind request and there is no other
+ external source of authentication credentials (e.g. IP-level
+ security [8]), or if, during the process of establishing the TLS
+ session, the server did not request the client's authentication
+ credentials, the SASL EXTERNAL bind MUST fail with a result code of
+ inappropriateAuthentication. Any client authentication and
+ authorization state of the LDAP association is lost, so the LDAP
+ association is in an anonymous state after the failure.
+
+9. Authorization Identity
+
+ The authorization identity is carried as part of the SASL credentials
+ field in the LDAP Bind request and response.
+
+ When the "EXTERNAL" mechanism is being negotiated, if the credentials
+ field is present, it contains an authorization identity of the
+ authzId form described below.
+
+ Other mechanisms define the location of the authorization identity in
+ the credentials field.
+
+ The authorization identity is a string in the UTF-8 character set,
+ corresponding to the following ABNF [7]:
+
+ ; Specific predefined authorization (authz) id schemes are
+ ; defined below -- new schemes may be defined in the future.
+
+ authzId = dnAuthzId / uAuthzId
+
+ ; distinguished-name-based authz id.
+ dnAuthzId = "dn:" dn
+ dn = utf8string ; with syntax defined in RFC 2253
+
+ ; unspecified userid, UTF-8 encoded.
+ uAuthzId = "u:" userid
+ userid = utf8string ; syntax unspecified
+
+ A utf8string is defined to be the UTF-8 encoding of one or more ISO
+ 10646 characters.
+
+ All servers which support the storage of authentication credentials,
+ such as passwords or certificates, in the directory MUST support the
+ dnAuthzId choice.
+
+
+
+
+
+Wahl, et al. Standards Track [Page 11]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+ The uAuthzId choice allows for compatibility with client applications
+ which wish to authenticate to a local directory but do not know their
+ own Distinguished Name or have a directory entry. The format of the
+ string is defined as only a sequence of UTF-8 encoded ISO 10646
+ characters, and further interpretation is subject to prior agreement
+ between the client and server.
+
+ For example, the userid could identify a user of a specific directory
+ service, or be a login name or the local-part of an RFC 822 email
+ address. In general a uAuthzId MUST NOT be assumed to be globally
+ unique.
+
+ Additional authorization identity schemes MAY be defined in future
+ versions of this document.
+
+10. TLS Ciphersuites
+
+ The following ciphersuites defined in [6] MUST NOT be used for
+ confidentiality protection of passwords or data:
+
+ TLS_NULL_WITH_NULL_NULL
+ TLS_RSA_WITH_NULL_MD5
+ TLS_RSA_WITH_NULL_SHA
+
+ The following ciphersuites defined in [6] can be cracked easily (less
+ than a week of CPU time on a standard CPU in 1997). The client and
+ server SHOULD carefully consider the value of the password or data
+ being protected before using these ciphersuites:
+
+ TLS_RSA_EXPORT_WITH_RC4_40_MD5
+ TLS_RSA_EXPORT_WITH_RC2_CBC_40_MD5
+ TLS_RSA_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_DSS_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_RSA_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DHE_DSS_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DHE_RSA_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
+ TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
+
+ The following ciphersuites are vulnerable to man-in-the-middle
+ attacks, and SHOULD NOT be used to protect passwords or sensitive
+ data, unless the network configuration is such that the danger of a
+ man-in-the-middle attack is tolerable:
+
+
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 12]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+ TLS_DH_anon_EXPORT_WITH_RC4_40_MD5
+ TLS_DH_anon_WITH_RC4_128_MD5
+ TLS_DH_anon_EXPORT_WITH_DES40_CBC_SHA
+ TLS_DH_anon_WITH_DES_CBC_SHA
+ TLS_DH_anon_WITH_3DES_EDE_CBC_SHA
+
+ A client or server that supports TLS MUST support at least
+ TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA.
+
+11. SASL service name for LDAP
+
+ For use with SASL [2], a protocol must specify a service name to be
+ used with various SASL mechanisms, such as GSSAPI. For LDAP, the
+ service name is "ldap", which has been registered with the IANA as a
+ GSSAPI service name.
+
+12. Security Considerations
+
+ Security issues are discussed throughout this memo; the
+ (unsurprising) conclusion is that mandatory security is important,
+ and that session encryption is required when snooping is a problem.
+
+ Servers are encouraged to prevent modifications by anonymous users.
+ Servers may also wish to minimize denial of service attacks by timing
+ out idle connections, and returning the unwillingToPerform result
+ code rather than performing computationally expensive operations
+ requested by unauthorized clients.
+
+ A connection on which the client has not performed the Start TLS
+ operation or negotiated a suitable SASL mechanism for connection
+ integrity and encryption services is subject to man-in-the-middle
+ attacks to view and modify information in transit.
+
+ Additional security considerations relating to the EXTERNAL mechanism
+ to negotiate TLS can be found in [2], [5] and [6].
+
+13. Acknowledgements
+
+ This document is a product of the LDAPEXT Working Group of the IETF.
+ The contributions of its members is greatly appreciated.
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 13]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+14. Bibliography
+
+ [1] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, December 1997.
+
+ [2] Myers, J., "Simple Authentication and Security Layer (SASL)", RFC
+ 2222, October 1997.
+
+ [3] Bradner, S., "Key words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [4] Leach, P. and C. Newman, "Using Digest Authentication as a SASL
+ Mechanism", RFC 2831, May 2000.
+
+ [5] Hodges, J., Morgan, R. and M. Wahl, "Lightweight Directory Access
+ Protocol (v3): Extension for Transport Layer Security", RFC 2830,
+ May 2000.
+
+ [6] Dierks, T. and C. Allen, "The TLS Protocol Version 1.0", RFC
+ 2246, January 1999.
+
+ [7] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [8] Kent, S. and R. Atkinson, "Security Architecture for the Internet
+ Protocol", RFC 2401, November 1998.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 14]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+15. Authors' Addresses
+
+ Mark Wahl
+ Sun Microsystems, Inc.
+ 8911 Capital of Texas Hwy #4140
+ Austin TX 78759
+ USA
+
+ EMail: M.Wahl@innosoft.com
+
+
+ Harald Tveit Alvestrand
+ EDB Maxware
+ Pirsenteret
+ N-7462 Trondheim, Norway
+
+ Phone: +47 73 54 57 97
+ EMail: Harald@Alvestrand.no
+
+
+ Jeff Hodges
+ Oblix, Inc.
+ 18922 Forge Drive
+ Cupertino, CA 95014
+ USA
+
+ Phone: +1-408-861-6656
+ EMail: JHodges@oblix.com
+
+
+ RL "Bob" Morgan
+ Computing and Communications
+ University of Washington
+ Seattle, WA 98105
+ USA
+
+ Phone: +1-206-221-3307
+ EMail: rlmorgan@washington.edu
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 15]
+
+RFC 2829 Authentication Methods for LDAP May 2000
+
+
+16. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, et al. Standards Track [Page 16]
+
Propchange: websites/production/directory/content/studio/users-guide/2.0.0.v20180908-M14/ldap_browser/rfc/rfc2829.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: websites/production/directory/content/studio/users-guide/2.0.0.v20180908-M14/ldap_browser/rfc/rfc2830.txt
==============================================================================
--- websites/production/directory/content/studio/users-guide/2.0.0.v20180908-M14/ldap_browser/rfc/rfc2830.txt (added)
+++ websites/production/directory/content/studio/users-guide/2.0.0.v20180908-M14/ldap_browser/rfc/rfc2830.txt Sun Sep 9 15:55:38 2018
@@ -0,0 +1,675 @@
+
+
+
+
+
+
+Network Working Group J. Hodges
+Request for Comments: 2830 Oblix Inc.
+Category: Standards Track R. Morgan
+ Univ of Washington
+ M. Wahl
+ Sun Microsystems, Inc.
+ May 2000
+
+
+ Lightweight Directory Access Protocol (v3):
+ Extension for Transport Layer Security
+
+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 defines the "Start Transport Layer Security (TLS)
+ Operation" for LDAP [LDAPv3, TLS]. This operation provides for TLS
+ establishment in an LDAP association and is defined in terms of an
+ LDAP extended request.
+
+1. Conventions Used in this Document
+
+ 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 [ReqsKeywords].
+
+2. The Start TLS Request
+
+ This section describes the Start TLS extended request and extended
+ response themselves: how to form the request, the form of the
+ response, and enumerates the various result codes the client MUST be
+ prepared to handle.
+
+ The section following this one then describes how to sequence an
+ overall Start TLS Operation.
+
+
+
+
+
+Hodges, et al. Standards Track [Page 1]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+2.1. Requesting TLS Establishment
+
+ A client may perform a Start TLS operation by transmitting an LDAP
+ PDU containing an ExtendedRequest [LDAPv3] specifying the OID for the
+ Start TLS operation:
+
+ 1.3.6.1.4.1.1466.20037
+
+ An LDAP ExtendedRequest is defined as follows:
+
+ ExtendedRequest ::= [APPLICATION 23] SEQUENCE {
+ requestName [0] LDAPOID,
+ requestValue [1] OCTET STRING OPTIONAL }
+
+ A Start TLS extended request is formed by setting the requestName
+ field to the OID string given above. The requestValue field is
+ absent. The client MUST NOT send any PDUs on this connection
+ following this request until it receives a Start TLS extended
+ response.
+
+ When a Start TLS extended request is made, the server MUST return an
+ LDAP PDU containing a Start TLS extended response. An LDAP
+ ExtendedResponse is defined as follows:
+
+ ExtendedResponse ::= [APPLICATION 24] SEQUENCE {
+ COMPONENTS OF LDAPResult,
+ responseName [10] LDAPOID OPTIONAL,
+ response [11] OCTET STRING OPTIONAL }
+
+ A Start TLS extended response MUST contain a responseName field which
+ MUST be set to the same string as that in the responseName field
+ present in the Start TLS extended request. The response field is
+ absent. The server MUST set the resultCode field to either success or
+ one of the other values outlined in section 2.3.
+
+2.2. "Success" Response
+
+ If the ExtendedResponse contains a resultCode of success, this
+ indicates that the server is willing and able to negotiate TLS. Refer
+ to section 3, below, for details.
+
+2.3. Response other than "success"
+
+ If the ExtendedResponse contains a resultCode other than success,
+ this indicates that the server is unwilling or unable to negotiate
+ TLS.
+
+
+
+
+
+Hodges, et al. Standards Track [Page 2]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+ If the Start TLS extended request was not successful, the resultCode
+ will be one of:
+
+ operationsError (operations sequencing incorrect; e.g. TLS already
+ established)
+
+ protocolError (TLS not supported or incorrect PDU structure)
+
+ referral (this server doesn't do TLS, try this one)
+
+ unavailable (e.g. some major problem with TLS, or server is
+ shutting down)
+
+ The server MUST return operationsError if the client violates any of
+ the Start TLS extended operation sequencing requirements described in
+ section 3, below.
+
+ If the server does not support TLS (whether by design or by current
+ configuration), it MUST set the resultCode to protocolError (see
+ section 4.1.1 of [LDAPv3]), or to referral. The server MUST include
+ an actual referral value in the LDAP Result if it returns a
+ resultCode of referral. The client's current session is unaffected if
+ the server does not support TLS. The client MAY proceed with any LDAP
+ operation, or it MAY close the connection.
+
+ The server MUST return unavailable if it supports TLS but cannot
+ establish a TLS connection for some reason, e.g. the certificate
+ server not responding, it cannot contact its TLS implementation, or
+ if the server is in process of shutting down. The client MAY retry
+ the StartTLS operation, or it MAY proceed with any other LDAP
+ operation, or it MAY close the connection.
+
+3. Sequencing of the Start TLS Operation
+
+ This section describes the overall procedures clients and servers
+ MUST follow for TLS establishment. These procedures take into
+ consideration various aspects of the overall security of the LDAP
+ association including discovery of resultant security level and
+ assertion of the client's authorization identity.
+
+ Note that the precise effects, on a client's authorization identity,
+ of establishing TLS on an LDAP association are described in detail in
+ section 5.
+
+
+
+
+
+
+
+
+Hodges, et al. Standards Track [Page 3]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+3.1. Requesting to Start TLS on an LDAP Association
+
+ The client MAY send the Start TLS extended request at any time after
+ establishing an LDAP association, except that in the following cases
+ the client MUST NOT send a Start TLS extended request:
+
+ - if TLS is currently established on the connection, or
+ - during a multi-stage SASL negotiation, or
+ - if there are any LDAP operations outstanding on the connection.
+
+ The result of violating any of these requirements is a resultCode of
+ operationsError, as described above in section 2.3.
+
+ The client MAY have already performed a Bind operation when it sends
+ a Start TLS request, or the client might have not yet bound.
+
+ If the client did not establish a TLS connection before sending any
+ other requests, and the server requires the client to establish a TLS
+ connection before performing a particular request, the server MUST
+ reject that request with a confidentialityRequired or
+ strongAuthRequired result. The client MAY send a Start TLS extended
+ request, or it MAY choose to close the connection.
+
+3.2. Starting TLS
+
+ The server will return an extended response with the resultCode of
+ success if it is willing and able to negotiate TLS. It will return
+ other resultCodes, documented above, if it is unable.
+
+ In the successful case, the client, which has ceased to transfer LDAP
+ requests on the connection, MUST either begin a TLS negotiation or
+ close the connection. The client will send PDUs in the TLS Record
+ Protocol directly over the underlying transport connection to the
+ server to initiate TLS negotiation [TLS].
+
+3.3. TLS Version Negotiation
+
+ Negotiating the version of TLS or SSL to be used is a part of the TLS
+ Handshake Protocol, as documented in [TLS]. Please refer to that
+ document for details.
+
+3.4. Discovery of Resultant Security Level
+
+ After a TLS connection is established on an LDAP association, both
+ parties MUST individually decide whether or not to continue based on
+ the privacy level achieved. Ascertaining the TLS connection's privacy
+ level is implementation dependent, and accomplished by communicating
+ with one's respective local TLS implementation.
+
+
+
+Hodges, et al. Standards Track [Page 4]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+ If the client or server decides that the level of authentication or
+ privacy is not high enough for it to continue, it SHOULD gracefully
+ close the TLS connection immediately after the TLS negotiation has
+ completed (see sections 4.1 and 5.2, below).
+
+ The client MAY attempt to Start TLS again, or MAY send an unbind
+ request, or send any other LDAP request.
+
+3.5. Assertion of Client's Authorization Identity
+
+ The client MAY, upon receipt of a Start TLS extended response
+ indicating success, assert that a specific authorization identity be
+ utilized in determining the client's authorization status. The client
+ accomplishes this via an LDAP Bind request specifying a SASL
+ mechanism of "EXTERNAL" [SASL]. See section 5.1.2, below.
+
+3.6. Server Identity Check
+
+ The client MUST check its understanding of the server's hostname
+ against the server's identity as presented in the server's
+ Certificate message, in order to prevent man-in-the-middle attacks.
+
+ Matching is performed according to these rules:
+
+ - The client MUST use the server hostname it used to open the LDAP
+ connection as the value to compare against the server name as
+ expressed in the server's certificate. The client MUST NOT use the
+ server's canonical DNS name or any other derived form of name.
+
+ - If a subjectAltName extension of type dNSName is present in the
+ certificate, it SHOULD be used as the source of the server's
+ identity.
+
+ - Matching is case-insensitive.
+
+ - The "*" wildcard character is allowed. If present, it applies only
+ to the left-most name component.
+
+ E.g. *.bar.com would match a.bar.com, b.bar.com, etc. but not
+ bar.com. If more than one identity of a given type is present in the
+ certificate (e.g. more than one dNSName name), a match in any one of
+ the set is considered acceptable.
+
+ If the hostname does not match the dNSName-based identity in the
+ certificate per the above check, user-oriented clients SHOULD either
+ notify the user (clients MAY give the user the opportunity to
+
+
+
+
+
+Hodges, et al. Standards Track [Page 5]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+ continue with the connection in any case) or terminate the connection
+ and indicate that the server's identity is suspect. Automated clients
+ SHOULD close the connection, returning and/or logging an error
+ indicating that the server's identity is suspect.
+
+ Beyond the server identity checks 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 observed to provide. The
+ client MAY need to make use of local policy information.
+
+3.7. Refresh of Server Capabilities Information
+
+ The client MUST refresh any cached server capabilities information
+ (e.g. from the server's root DSE; see section 3.4 of [LDAPv3]) upon
+ TLS session establishment. This is necessary to protect against
+ active-intermediary attacks which may have altered any server
+ capabilities information retrieved prior to TLS establishment. The
+ server MAY advertise different capabilities after TLS establishment.
+
+4. Closing a TLS Connection
+
+4.1. Graceful Closure
+
+ Either the client or server MAY terminate the TLS connection on an
+ LDAP association by sending a TLS closure alert. This will leave the
+ LDAP association intact.
+
+ Before closing a TLS connection, the client MUST either wait for any
+ outstanding LDAP operations to complete, or explicitly abandon them
+ [LDAPv3].
+
+ After the initiator of a close has sent a closure alert, it MUST
+ discard any TLS messages until it has received an alert from the
+ other party. It will cease to send TLS Record Protocol PDUs, and
+ following the receipt of the alert, MAY send and receive LDAP PDUs.
+
+ The other party, if it receives a closure alert, MUST immediately
+ transmit a TLS closure alert. It will subsequently cease to send TLS
+ Record Protocol PDUs, and MAY send and receive LDAP PDUs.
+
+4.2. Abrupt Closure
+
+ Either the client or server MAY abruptly close the entire LDAP
+ association and any TLS connection established on it by dropping the
+ underlying TCP connection. A server MAY beforehand send the client a
+ Notice of Disconnection [LDAPv3] in this case.
+
+
+
+
+
+Hodges, et al. Standards Track [Page 6]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+5. Effects of TLS on a Client's Authorization Identity
+
+ This section describes the effects on a client's authorization
+ identity brought about by establishing TLS on an LDAP association.
+ The default effects are described first, and next the facilities for
+ client assertion of authorization identity are discussed including
+ error conditions. Lastly, the effects of closing the TLS connection
+ are described.
+
+ Authorization identities and related concepts are defined in
+ [AuthMeth].
+
+5.1. TLS Connection Establishment Effects
+
+5.1.1. Default Effects
+
+ Upon establishment of the TLS connection onto the LDAP association,
+ any previously established authentication and authorization
+ identities MUST remain in force, including anonymous state. This
+ holds even in the case where the server requests client
+ authentication via TLS -- e.g. requests the client to supply its
+ certificate during TLS negotiation (see [TLS]).
+
+5.1.2. Client Assertion of Authorization Identity
+
+ A client MAY either implicitly request that its LDAP authorization
+ identity be derived from its authenticated TLS credentials or it MAY
+ explicitly provide an authorization identity and assert that it be
+ used in combination with its authenticated TLS credentials. The
+ former is known as an implicit assertion, and the latter as an
+ explicit assertion.
+
+5.1.2.1. Implicit Assertion
+
+ An implicit authorization identity assertion is accomplished after
+ TLS establishment by invoking a Bind request of the SASL form using
+ the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL NOT include
+ the optional credentials octet string (found within the
+ SaslCredentials sequence in the Bind Request). The server will derive
+ the client's authorization identity from the authentication identity
+ supplied in the client's TLS credentials (typically a public key
+ certificate) according to local policy. The underlying mechanics of
+ how this is accomplished are implementation specific.
+
+
+
+
+
+
+
+
+Hodges, et al. Standards Track [Page 7]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+5.1.2.2. Explicit Assertion
+
+ An explicit authorization identity assertion is accomplished after
+ TLS establishment by invoking a Bind request of the SASL form using
+ the "EXTERNAL" mechanism name [SASL, LDAPv3] that SHALL include the
+ credentials octet string. This string MUST be constructed as
+ documented in section 9 of [AuthMeth].
+
+5.1.2.3. Error Conditions
+
+ For either form of assertion, the server MUST verify that the
+ client's authentication identity as supplied in its TLS credentials
+ is permitted to be mapped to the asserted authorization identity. The
+ server MUST reject the Bind operation with an invalidCredentials
+ resultCode in the Bind response if the client is not so authorized.
+
+ Additionally, with either form of assertion, if a TLS session has not
+ been established between the client and server prior to making the
+ SASL EXTERNAL Bind request and there is no other external source of
+ authentication credentials (e.g. IP-level security [IPSEC]), or if,
+ during the process of establishing the TLS session, the server did
+ not request the client's authentication credentials, the SASL
+ EXTERNAL bind MUST fail with a result code of
+ inappropriateAuthentication.
+
+ After the above Bind operation failures, any client authentication
+ and authorization state of the LDAP association is lost, so the LDAP
+ association is in an anonymous state after the failure. TLS
+ connection state is unaffected, though a server MAY end the TLS
+ connection, via a TLS close_notify message, based on the Bind failure
+ (as it MAY at any time).
+
+5.2. TLS Connection Closure Effects
+
+ Closure of the TLS connection MUST cause the LDAP association to move
+ to an anonymous authentication and authorization state regardless of
+ the state established over TLS and regardless of the authentication
+ and authorization state prior to TLS connection establishment.
+
+6. Security Considerations
+
+ The goals of using the TLS protocol with LDAP are to ensure
+ connection confidentiality and integrity, and to optionally provide
+ for authentication. TLS expressly provides these capabilities, as
+ described in [TLS].
+
+
+
+
+
+
+Hodges, et al. Standards Track [Page 8]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+ All security gained via use of the Start TLS operation is gained by
+ the use of TLS itself. The Start TLS operation, on its own, does not
+ provide any additional security.
+
+ The use of TLS does not provide or ensure for confidentiality and/or
+ non-repudiation of the data housed by an LDAP-based directory server.
+ Nor does it secure the data from inspection by the server
+ administrators. Once established, TLS only provides for and ensures
+ confidentiality and integrity of the operations and data in transit
+ over the LDAP association, and only if the implementations on the
+ client and server support and negotiate it.
+
+ The level of security provided though the use of TLS depends directly
+ on both the quality of the TLS implementation used and the style of
+ usage of that implementation. Additionally, an active-intermediary
+ attacker can remove the Start TLS extended operation from the
+ supportedExtension attribute of the root DSE. Therefore, both parties
+ SHOULD independently ascertain and consent to the security level
+ achieved once TLS is established and before beginning use of the TLS
+ connection. For example, the security level of the TLS connection
+ might have been negotiated down to plaintext.
+
+ Clients SHOULD either warn the user when the security level achieved
+ does not provide confidentiality and/or integrity protection, or be
+ configurable to refuse to proceed without an acceptable level of
+ security.
+
+ Client and server implementors SHOULD take measures to ensure proper
+ protection of credentials and other confidential data where such
+ measures are not otherwise provided by the TLS implementation.
+
+ Server implementors SHOULD allow for server administrators to elect
+ whether and when connection confidentiality and/or integrity is
+ required, as well as elect whether and when client authentication via
+ TLS is required.
+
+7. Acknowledgements
+
+ The authors thank Tim Howes, Paul Hoffman, John Kristian, Shirish
+ Rai, Jonathan Trostle, Harald Alvestrand, and Marcus Leech for their
+ contributions to this document.
+
+
+
+
+
+
+
+
+
+
+Hodges, et al. Standards Track [Page 9]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+8. References
+
+ [AuthMeth] Wahl, M., Alvestrand, H., Hodges, J. and R. Morgan,
+ "Authentication Methods for LDAP", RFC 2829, May 2000.
+
+ [IPSEC] Kent, S. and R. Atkinson, "Security Architecture for
+ the Internet Protocol", RFC 2401, November 1998.
+
+ [LDAPv3] Wahl, M., Kille S. and T. Howes, "Lightweight
+ Directory Access Protocol (v3)", RFC 2251, December
+ 1997.
+
+ [ReqsKeywords] Bradner, S., "Key Words for use in RFCs to Indicate
+ Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+ [SASL] Myers, J., "Simple Authentication and Security Layer
+ (SASL)", RFC 2222, October 1997.
+
+ [TLS] Dierks, T. and C. Allen. "The TLS Protocol Version
+ 1.0", RFC 2246, January 1999.
+
+9. Authors' Addresses
+
+ Jeff Hodges
+ Oblix, Inc.
+ 18922 Forge Drive
+ Cupertino, CA 95014
+ USA
+
+ Phone: +1-408-861-6656
+ EMail: JHodges@oblix.com
+
+ RL "Bob" Morgan
+ Computing and Communications
+ University of Washington
+ Seattle, WA
+ USA
+
+ Phone: +1-206-221-3307
+ EMail: rlmorgan@washington.edu
+
+ Mark Wahl
+ Sun Microsystems, Inc.
+ 8911 Capital of Texas Hwy #4140
+ Austin TX 78759
+ USA
+
+ EMail: M.Wahl@innosoft.com
+
+
+
+Hodges, et al. Standards Track [Page 10]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+10. Intellectual Property Rights Notices
+
+ The IETF takes no position regarding the validity or scope of any
+ intellectual property or other rights that might be claimed to
+ pertain to the implementation or use of the technology described in
+ this document or the extent to which any license under such rights
+ might or might not be available; neither does it represent that it
+ has made any effort to identify any such rights. Information on the
+ IETF's procedures with respect to rights in standards-track and
+ standards-related documentation can be found in BCP-11. Copies of
+ claims of rights made available for publication and any assurances of
+ licenses to be made available, or the result of an attempt made to
+ obtain a general license or permission for the use of such
+ proprietary rights by implementors or users of this specification can
+ be obtained from the IETF Secretariat.
+
+ The IETF invites any interested party to bring to its attention any
+ copyrights, patents or patent applications, or other proprietary
+ rights which may cover technology that may be required to practice
+ this standard. Please address the information to the IETF Executive
+ Director.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hodges, et al. Standards Track [Page 11]
+
+RFC 2830 LDAPv3: Extension for Transport Layer Security May 2000
+
+
+11. Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Hodges, et al. Standards Track [Page 12]
+
Propchange: websites/production/directory/content/studio/users-guide/2.0.0.v20180908-M14/ldap_browser/rfc/rfc2830.txt
------------------------------------------------------------------------------
svn:eol-style = native
Added: websites/production/directory/content/studio/users-guide/2.0.0.v20180908-M14/ldap_browser/rfc/rfc2849.txt
==============================================================================
--- websites/production/directory/content/studio/users-guide/2.0.0.v20180908-M14/ldap_browser/rfc/rfc2849.txt (added)
+++ websites/production/directory/content/studio/users-guide/2.0.0.v20180908-M14/ldap_browser/rfc/rfc2849.txt Sun Sep 9 15:55:38 2018
@@ -0,0 +1,787 @@
+
+
+
+
+
+
+Network Working Group G. Good
+Request for Comments: 2849 iPlanet e-commerce Solutions
+Category: Standards Track June 2000
+
+
+ The LDAP Data Interchange Format (LDIF) - Technical Specification
+
+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 describes a file format suitable for describing
+ directory information or modifications made to directory information.
+ The file format, known as LDIF, for LDAP Data Interchange Format, is
+ typically used to import and export directory information between
+ LDAP-based directory servers, or to describe a set of changes which
+ are to be applied to a directory.
+
+Background and Intended Usage
+
+ There are a number of situations where a common interchange format is
+ desirable. For example, one might wish to export a copy of the
+ contents of a directory server to a file, move that file to a
+ different machine, and import the contents into a second directory
+ server.
+
+ Additionally, by using a well-defined interchange format, development
+ of data import tools from legacy systems is facilitated. A fairly
+ simple set of tools written in awk or perl can, for example, convert
+ a database of personnel information into an LDIF file. This file can
+ then be imported into a directory server, regardless of the internal
+ database representation the target directory server uses.
+
+ The LDIF format was originally developed and used in the University
+ of Michigan LDAP implementation. The first use of LDIF was in
+ describing directory entries. Later, the format was expanded to
+ allow representation of changes to directory entries.
+
+
+
+
+Good Standards Track [Page 1]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+ Relationship to the application/directory MIME content-type:
+
+ The application/directory MIME content-type [1] is a general
+ framework and format for conveying directory information, and is
+ independent of any particular directory service. The LDIF format is
+ a simpler format which is perhaps easier to create, and may also be
+ used, as noted, to describe a set of changes to be applied to a
+ directory.
+
+ The key words "MUST", "MUST NOT", "MAY", "SHOULD", and "SHOULD NOT"
+ used in this document are to be interpreted as described in [7].
+
+Definition of the LDAP Data Interchange Format
+
+ The LDIF format is used to convey directory information, or a
+ description of a set of changes made to directory entries. An LDIF
+ file consists of a series of records separated by line separators. A
+ record consists of a sequence of lines describing a directory entry,
+ or a sequence of lines describing a set of changes to a directory
+ entry. An LDIF file specifies a set of directory entries, or a set
+ of changes to be applied to directory entries, but not both.
+
+ There is a one-to-one correlation between LDAP operations that modify
+ the directory (add, delete, modify, and modrdn), and the types of
+ changerecords described below ("add", "delete", "modify", and
+ "modrdn" or "moddn"). This correspondence is intentional, and
+ permits a straightforward translation from LDIF changerecords to
+ protocol operations.
+
+Formal Syntax Definition of LDIF
+
+ The following definition uses the augmented Backus-Naur Form
+ specified in RFC 2234 [2].
+
+ldif-file = ldif-content / ldif-changes
+
+ldif-content = version-spec 1*(1*SEP ldif-attrval-record)
+
+ldif-changes = version-spec 1*(1*SEP ldif-change-record)
+
+ldif-attrval-record = dn-spec SEP 1*attrval-spec
+
+ldif-change-record = dn-spec SEP *control changerecord
+
+version-spec = "version:" FILL version-number
+
+
+
+
+
+
+Good Standards Track [Page 2]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+version-number = 1*DIGIT
+ ; version-number MUST be "1" for the
+ ; LDIF format described in this document.
+
+dn-spec = "dn:" (FILL distinguishedName /
+ ":" FILL base64-distinguishedName)
+
+distinguishedName = SAFE-STRING
+ ; a distinguished name, as defined in [3]
+
+base64-distinguishedName = BASE64-UTF8-STRING
+ ; a distinguishedName which has been base64
+ ; encoded (see note 10, below)
+
+rdn = SAFE-STRING
+ ; a relative distinguished name, defined as
+ ; <name-component> in [3]
+
+base64-rdn = BASE64-UTF8-STRING
+ ; an rdn which has been base64 encoded (see
+ ; note 10, below)
+
+control = "control:" FILL ldap-oid ; controlType
+ 0*1(1*SPACE ("true" / "false")) ; criticality
+ 0*1(value-spec) ; controlValue
+ SEP
+ ; (See note 9, below)
+
+ldap-oid = 1*DIGIT 0*1("." 1*DIGIT)
+ ; An LDAPOID, as defined in [4]
+
+attrval-spec = AttributeDescription value-spec SEP
+
+value-spec = ":" ( FILL 0*1(SAFE-STRING) /
+ ":" FILL (BASE64-STRING) /
+ "<" FILL url)
+ ; See notes 7 and 8, below
+
+url = <a Uniform Resource Locator,
+ as defined in [6]>
+ ; (See Note 6, below)
+
+AttributeDescription = AttributeType [";" options]
+ ; Definition taken from [4]
+
+AttributeType = ldap-oid / (ALPHA *(attr-type-chars))
+
+options = option / (option ";" options)
+
+
+
+Good Standards Track [Page 3]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+option = 1*opt-char
+
+attr-type-chars = ALPHA / DIGIT / "-"
+
+opt-char = attr-type-chars
+
+changerecord = "changetype:" FILL
+ (change-add / change-delete /
+ change-modify / change-moddn)
+
+change-add = "add" SEP 1*attrval-spec
+
+change-delete = "delete" SEP
+
+change-moddn = ("modrdn" / "moddn") SEP
+ "newrdn:" ( FILL rdn /
+ ":" FILL base64-rdn) SEP
+ "deleteoldrdn:" FILL ("0" / "1") SEP
+ 0*1("newsuperior:"
+ ( FILL distinguishedName /
+ ":" FILL base64-distinguishedName) SEP)
+
+change-modify = "modify" SEP *mod-spec
+
+mod-spec = ("add:" / "delete:" / "replace:")
+ FILL AttributeDescription SEP
+ *attrval-spec
+ "-" SEP
+
+SPACE = %x20
+ ; ASCII SP, space
+
+FILL = *SPACE
+
+SEP = (CR LF / LF)
+
+CR = %x0D
+ ; ASCII CR, carriage return
+
+LF = %x0A
+ ; ASCII LF, line feed
+
+ALPHA = %x41-5A / %x61-7A
+ ; A-Z / a-z
+
+DIGIT = %x30-39
+ ; 0-9
+
+
+
+
+Good Standards Track [Page 4]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+UTF8-1 = %x80-BF
+
+UTF8-2 = %xC0-DF UTF8-1
+
+UTF8-3 = %xE0-EF 2UTF8-1
+
+UTF8-4 = %xF0-F7 3UTF8-1
+
+UTF8-5 = %xF8-FB 4UTF8-1
+
+UTF8-6 = %xFC-FD 5UTF8-1
+
+SAFE-CHAR = %x01-09 / %x0B-0C / %x0E-7F
+ ; any value <= 127 decimal except NUL, LF,
+ ; and CR
+
+SAFE-INIT-CHAR = %x01-09 / %x0B-0C / %x0E-1F /
+ %x21-39 / %x3B / %x3D-7F
+ ; any value <= 127 except NUL, LF, CR,
+ ; SPACE, colon (":", ASCII 58 decimal)
+ ; and less-than ("<" , ASCII 60 decimal)
+
+SAFE-STRING = [SAFE-INIT-CHAR *SAFE-CHAR]
+
+UTF8-CHAR = SAFE-CHAR / UTF8-2 / UTF8-3 /
+ UTF8-4 / UTF8-5 / UTF8-6
+
+UTF8-STRING = *UTF8-CHAR
+
+BASE64-UTF8-STRING = BASE64-STRING
+ ; MUST be the base64 encoding of a
+ ; UTF8-STRING
+
+BASE64-CHAR = %x2B / %x2F / %x30-39 / %x3D / %x41-5A /
+ %x61-7A
+ ; +, /, 0-9, =, A-Z, and a-z
+ ; as specified in [5]
+
+BASE64-STRING = [*(BASE64-CHAR)]
+
+
+ Notes on LDIF Syntax
+
+ 1) For the LDIF format described in this document, the version
+ number MUST be "1". If the version number is absent,
+ implementations MAY choose to interpret the contents as an
+ older LDIF file format, supported by the University of
+ Michigan ldap-3.3 implementation [8].
+
+
+
+Good Standards Track [Page 5]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+ 2) Any non-empty line, including comment lines, in an LDIF file
+ MAY be folded by inserting a line separator (SEP) and a SPACE.
+ Folding MUST NOT occur before the first character of the line.
+ In other words, folding a line into two lines, the first of
+ which is empty, is not permitted. Any line that begins with a
+ single space MUST be treated as a continuation of the previous
+ (non-empty) line. When joining folded lines, exactly one space
+ character at the beginning of each continued line must be
+ discarded. Implementations SHOULD NOT fold lines in the middle
+ of a multi-byte UTF-8 character.
+
+ 3) Any line that begins with a pound-sign ("#", ASCII 35) is a
+ comment line, and MUST be ignored when parsing an LDIF file.
+
+ 4) Any dn or rdn that contains characters other than those
+ defined as "SAFE-UTF8-CHAR", or begins with a character other
+ than those defined as "SAFE-INIT-UTF8-CHAR", above, MUST be
+ base-64 encoded. Other values MAY be base-64 encoded. Any
+ value that contains characters other than those defined as
+ "SAFE-CHAR", or begins with a character other than those
+ defined as "SAFE-INIT-CHAR", above, MUST be base-64 encoded.
+ Other values MAY be base-64 encoded.
+
+ 5) When a zero-length attribute value is to be included directly
+ in an LDIF file, it MUST be represented as
+ AttributeDescription ":" FILL SEP. For example, "seeAlso:"
+ followed by a newline represents a zero-length "seeAlso"
+ attribute value. It is also permissible for the value
+ referred to by a URL to be of zero length.
+
+ 6) When a URL is specified in an attrval-spec, the following
+ conventions apply:
+
+ a) Implementations SHOULD support the file:// URL format. The
+ contents of the referenced file are to be included verbatim
+ in the interpreted output of the LDIF file.
+ b) Implementations MAY support other URL formats. The
+ semantics associated with each supported URL will be
+ documented in an associated Applicability Statement.
+
+ 7) Distinguished names, relative distinguished names, and
+ attribute values of DirectoryString syntax MUST be valid UTF-8
+ strings. Implementations that read LDIF MAY interpret files
+ in which these entities are stored in some other character set
+ encoding, but implementations MUST NOT generate LDIF content
+ which does not contain valid UTF-8 data.
+
+
+
+
+
+Good Standards Track [Page 6]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+ 8) Values or distinguished names that end with SPACE SHOULD be
+ base-64 encoded.
+
+ 9) When controls are included in an LDIF file, implementations
+ MAY choose to ignore some or all of them. This may be
+ necessary if the changes described in the LDIF file are being
+ sent on an LDAPv2 connection (LDAPv2 does not support
+ controls), or the particular controls are not supported by the
+ remote server. If the criticality of a control is "true", then
+ the implementation MUST either include the control, or MUST
+ NOT send the operation to a remote server.
+
+ 10) When an attrval-spec, distinguishedName, or rdn is base64-
+ encoded, the encoding rules specified in [5] are used with the
+ following exceptions: a) The requirement that base64 output
+ streams must be represented as lines of no more than 76
+ characters is removed. Lines in LDIF files may only be folded
+ according to the folding rules described in note 2, above. b)
+ Base64 strings in [5] may contain characters other than those
+ defined in BASE64-CHAR, and are ignored. LDIF does not permit
+ any extraneous characters, other than those used for line
+ folding.
+
+Examples of LDAP Data Interchange Format
+
+Example 1: An simple LDAP file with two entries
+
+version: 1
+dn: cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Barbara Jensen
+cn: Barbara J Jensen
+cn: Babs Jensen
+sn: Jensen
+uid: bjensen
+telephonenumber: +1 408 555 1212
+description: A big sailing fan.
+
+dn: cn=Bjorn Jensen, ou=Accounting, dc=airius, dc=com
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Bjorn Jensen
+sn: Jensen
+telephonenumber: +1 408 555 1212
+
+
+
+
+Good Standards Track [Page 7]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+Example 2: A file containing an entry with a folded attribute value
+
+version: 1
+dn:cn=Barbara Jensen, ou=Product Development, dc=airius, dc=com
+objectclass:top
+objectclass:person
+objectclass:organizationalPerson
+cn:Barbara Jensen
+cn:Barbara J Jensen
+cn:Babs Jensen
+sn:Jensen
+uid:bjensen
+telephonenumber:+1 408 555 1212
+description:Babs is a big sailing fan, and travels extensively in sea
+ rch of perfect sailing conditions.
+title:Product Manager, Rod and Reel Division
+
+Example 3: A file containing a base-64-encoded value
+
+version: 1
+dn: cn=Gern Jensen, ou=Product Testing, dc=airius, dc=com
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Gern Jensen
+cn: Gern O Jensen
+sn: Jensen
+uid: gernj
+telephonenumber: +1 408 555 1212
+description:: V2hhdCBhIGNhcmVmdWwgcmVhZGVyIHlvdSBhcmUhICBUaGlzIHZhbHVl
+IGlzIGJhc2UtNjQtZW5jb2RlZCBiZWNhdXNlIGl0IGhhcyBhIGNvbnRyb2wgY2hhcmFjdG
+VyIGluIGl0IChhIENSKS4NICBCeSB0aGUgd2F5LCB5b3Ugc2hvdWxkIHJlYWxseSBnZXQg
+b3V0IG1vcmUu
+
+Example 4: A file containing an entries with UTF-8-encoded attribute
+values, including language tags. Comments indicate the contents
+of UTF-8-encoded attributes and distinguished names.
+
+version: 1
+dn:: b3U95Za25qWt6YOoLG89QWlyaXVz
+# dn:: ou=<JapaneseOU>,o=Airius
+objectclass: top
+objectclass: organizationalUnit
+ou:: 5Za25qWt6YOo
+# ou:: <JapaneseOU>
+ou;lang-ja:: 5Za25qWt6YOo
+# ou;lang-ja:: <JapaneseOU>
+ou;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2
+
+
+
+Good Standards Track [Page 8]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+# ou;lang-ja:: <JapaneseOU_in_phonetic_representation>
+ou;lang-en: Sales
+description: Japanese office
+
+dn:: dWlkPXJvZ2FzYXdhcmEsb3U95Za25qWt6YOoLG89QWlyaXVz
+# dn:: uid=<uid>,ou=<JapaneseOU>,o=Airius
+userpassword: {SHA}O3HSv1MusyL4kTjP+HKI5uxuNoM=
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+objectclass: inetOrgPerson
+uid: rogasawara
+mail: rogasawara@airius.co.jp
+givenname;lang-ja:: 44Ot44OJ44OL44O8
+# givenname;lang-ja:: <JapaneseGivenname>
+sn;lang-ja:: 5bCP56yg5Y6f
+# sn;lang-ja:: <JapaneseSn>
+cn;lang-ja:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
+# cn;lang-ja:: <JapaneseCn>
+title;lang-ja:: 5Za25qWt6YOoIOmDqOmVtw==
+# title;lang-ja:: <JapaneseTitle>
+preferredlanguage: ja
+givenname:: 44Ot44OJ44OL44O8
+# givenname:: <JapaneseGivenname>
+sn:: 5bCP56yg5Y6f
+# sn:: <JapaneseSn>
+cn:: 5bCP56yg5Y6fIOODreODieODi+ODvA==
+# cn:: <JapaneseCn>
+title:: 5Za25qWt6YOoIOmDqOmVtw==
+# title:: <JapaneseTitle>
+givenname;lang-ja;phonetic:: 44KN44Gp44Gr44O8
+# givenname;lang-ja;phonetic::
+<JapaneseGivenname_in_phonetic_representation_kana>
+sn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJ
+# sn;lang-ja;phonetic:: <JapaneseSn_in_phonetic_representation_kana>
+cn;lang-ja;phonetic:: 44GK44GM44GV44KP44KJIOOCjeOBqeOBq+ODvA==
+# cn;lang-ja;phonetic:: <JapaneseCn_in_phonetic_representation_kana>
+title;lang-ja;phonetic:: 44GI44GE44GO44KH44GG44G2IOOBtuOBoeOCh+OBhg==
+# title;lang-ja;phonetic::
+# <JapaneseTitle_in_phonetic_representation_kana>
+givenname;lang-en: Rodney
+sn;lang-en: Ogasawara
+cn;lang-en: Rodney Ogasawara
+title;lang-en: Sales, Director
+
+
+
+
+
+
+
+Good Standards Track [Page 9]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+Example 5: A file containing a reference to an external file
+
+version: 1
+dn: cn=Horatio Jensen, ou=Product Testing, dc=airius, dc=com
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Horatio Jensen
+
+cn: Horatio N Jensen
+sn: Jensen
+uid: hjensen
+telephonenumber: +1 408 555 1212
+jpegphoto:< file:///usr/local/directory/photos/hjensen.jpg
+
+Example 6: A file containing a series of change records and comments
+
+version: 1
+# Add a new entry
+dn: cn=Fiona Jensen, ou=Marketing, dc=airius, dc=com
+changetype: add
+objectclass: top
+objectclass: person
+objectclass: organizationalPerson
+cn: Fiona Jensen
+sn: Jensen
+uid: fiona
+telephonenumber: +1 408 555 1212
+jpegphoto:< file:///usr/local/directory/photos/fiona.jpg
+
+# Delete an existing entry
+dn: cn=Robert Jensen, ou=Marketing, dc=airius, dc=com
+changetype: delete
+
+# Modify an entry's relative distinguished name
+dn: cn=Paul Jensen, ou=Product Development, dc=airius, dc=com
+changetype: modrdn
+newrdn: cn=Paula Jensen
+deleteoldrdn: 1
+
+# Rename an entry and move all of its children to a new location in
+# the directory tree (only implemented by LDAPv3 servers).
+dn: ou=PD Accountants, ou=Product Development, dc=airius, dc=com
+changetype: modrdn
+newrdn: ou=Product Development Accountants
+deleteoldrdn: 0
+newsuperior: ou=Accounting, dc=airius, dc=com
+
+
+
+
+Good Standards Track [Page 10]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+# Modify an entry: add an additional value to the postaladdress
+# attribute, completely delete the description attribute, replace
+# the telephonenumber attribute with two values, and delete a specific
+# value from the facsimiletelephonenumber attribute
+dn: cn=Paula Jensen, ou=Product Development, dc=airius, dc=com
+changetype: modify
+add: postaladdress
+postaladdress: 123 Anystreet $ Sunnyvale, CA $ 94086
+-
+
+delete: description
+-
+replace: telephonenumber
+telephonenumber: +1 408 555 1234
+telephonenumber: +1 408 555 5678
+-
+delete: facsimiletelephonenumber
+facsimiletelephonenumber: +1 408 555 9876
+-
+
+# Modify an entry: replace the postaladdress attribute with an empty
+# set of values (which will cause the attribute to be removed), and
+# delete the entire description attribute. Note that the first will
+# always succeed, while the second will only succeed if at least
+# one value for the description attribute is present.
+dn: cn=Ingrid Jensen, ou=Product Support, dc=airius, dc=com
+changetype: modify
+replace: postaladdress
+-
+delete: description
+-
+
+Example 7: An LDIF file containing a change record with a control
+version: 1
+# Delete an entry. The operation will attach the LDAPv3
+# Tree Delete Control defined in [9]. The criticality
+# field is "true" and the controlValue field is
+# absent, as required by [9].
+dn: ou=Product Development, dc=airius, dc=com
+control: 1.2.840.113556.1.4.805 true
+changetype: delete
+
+
+
+
+
+
+
+
+
+
+Good Standards Track [Page 11]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+Security Considerations
+
+ Given typical directory applications, an LDIF file is likely to
+ contain sensitive personal data. Appropriate measures should be
+ taken to protect the privacy of those persons whose data is contained
+ in an LDIF file.
+
+ Since ":<" directives can cause external content to be included when
+ processing an LDIF file, one should be cautious of accepting LDIF
+ files from external sources. A "trojan" LDIF file could name a file
+ with sensitive contents and cause it to be included in a directory
+ entry, which a hostile entity could read via LDAP.
+
+ LDIF does not provide any method for carrying authentication
+ information with an LDIF file. Users of LDIF files must take care to
+ verify the integrity of an LDIF file received from an external
+ source.
+
+Acknowledgments
+
+ The LDAP Interchange Format was developed as part of the University
+ of Michigan LDAP reference implementation, and was developed by Tim
+ Howes, Mark Smith, and Gordon Good. It is based in part upon work
+ supported by the National Science Foundation under Grant No. NCR-
+ 9416667.
+
+ Members of the IETF LDAP Extensions Working group provided many
+ helpful suggestions. In particular, Hallvard B. Furuseth of the
+ University of Oslo made many significant contributions to this
+ document, including a thorough review and rewrite of the BNF.
+
+References
+
+ [1] Howes, T. and M. Smith, "A MIME Content-Type for Directory
+ Information", RFC 2425, September 1998.
+
+ [2] Crocker, D., and P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234, November 1997.
+
+ [3] Wahl, M., Kille, S. and T. Howes, "A String Representation of
+ Distinguished Names", RFC 2253, December 1997.
+
+ [4] Wahl, M., Howes, T. and S. Kille, "Lightweight Directory Access
+ Protocol (v3)", RFC 2251, July 1997.
+
+ [5] Freed, N. and N. Borenstein, "Multipurpose Internet Mail
+ Extensions (MIME) Part One: Format of Internet Message Bodies",
+ RFC 2045, November 1996.
+
+
+
+Good Standards Track [Page 12]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+ [6] Berners-Lee, T., Masinter, L. and M. McCahill, "Uniform
+ Resource Locators (URL)", RFC 1738, December 1994.
+
+ [7] Bradner, S., "Key Words for use in RFCs to Indicate Requirement
+ Levels", BCP 14, RFC 2119, March 1997.
+
+ [8] The SLAPD and SLURPD Administrators Guide. University of
+ Michigan, April 1996. <URL:
+ http://www.umich.edu/~dirsvcs/ldap/doc/guides/slapd/toc.html>
+
+ [9] M. P. Armijo, "Tree Delete Control", Work in Progress.
+
+Author's Address
+
+ Gordon Good
+ iPlanet e-commerce Solutions
+ 150 Network Circle
+ Mailstop USCA17-201
+ Santa Clara, CA 95054, USA
+
+ Phone: +1 408 276 4351
+ EMail: ggood@netscape.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Good Standards Track [Page 13]
+
+RFC 2849 LDAP Data Interchange Format June 2000
+
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (2000). All Rights Reserved.
+
+ This document and translations of it may be copied and furnished to
+ others, and derivative works that comment on or otherwise explain it
+ or assist in its implementation may be prepared, copied, published
+ and distributed, in whole or in part, without restriction of any
+ kind, provided that the above copyright notice and this paragraph are
+ included on all such copies and derivative works. However, this
+ document itself may not be modified in any way, such as by removing
+ the copyright notice or references to the Internet Society or other
+ Internet organizations, except as needed for the purpose of
+ developing Internet standards in which case the procedures for
+ copyrights defined in the Internet Standards process must be
+ followed, or as required to translate it into languages other than
+ English.
+
+ The limited permissions granted above are perpetual and will not be
+ revoked by the Internet Society or its successors or assigns.
+
+ This document and the information contained herein is provided on an
+ "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
+ TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
+ BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
+ HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
+ MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
+
+Acknowledgement
+
+ Funding for the RFC Editor function is currently provided by the
+ Internet Society.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Good Standards Track [Page 14]
+
Propchange: websites/production/directory/content/studio/users-guide/2.0.0.v20180908-M14/ldap_browser/rfc/rfc2849.txt
------------------------------------------------------------------------------
svn:eol-style = native