directory-commits mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From seelm...@apache.org
Subject svn commit: r500049 [5/14] - in /directory/ldapstudio/trunk/ldapstudio-browser-help: resources/rfc/ src/main/resources/
Date Thu, 25 Jan 2007 23:21:19 GMT
Added: directory/ldapstudio/trunk/ldapstudio-browser-help/resources/rfc/rfc2829.txt
URL: http://svn.apache.org/viewvc/directory/ldapstudio/trunk/ldapstudio-browser-help/resources/rfc/rfc2829.txt?view=auto&rev=500049
==============================================================================
--- directory/ldapstudio/trunk/ldapstudio-browser-help/resources/rfc/rfc2829.txt (added)
+++ directory/ldapstudio/trunk/ldapstudio-browser-help/resources/rfc/rfc2829.txt Thu Jan 25 15:21:17 2007
@@ -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]
+

Added: directory/ldapstudio/trunk/ldapstudio-browser-help/resources/rfc/rfc2830.txt
URL: http://svn.apache.org/viewvc/directory/ldapstudio/trunk/ldapstudio-browser-help/resources/rfc/rfc2830.txt?view=auto&rev=500049
==============================================================================
--- directory/ldapstudio/trunk/ldapstudio-browser-help/resources/rfc/rfc2830.txt (added)
+++ directory/ldapstudio/trunk/ldapstudio-browser-help/resources/rfc/rfc2830.txt Thu Jan 25 15:21:17 2007
@@ -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]
+

Added: directory/ldapstudio/trunk/ldapstudio-browser-help/resources/rfc/rfc2849.txt
URL: http://svn.apache.org/viewvc/directory/ldapstudio/trunk/ldapstudio-browser-help/resources/rfc/rfc2849.txt?view=auto&rev=500049
==============================================================================
--- directory/ldapstudio/trunk/ldapstudio-browser-help/resources/rfc/rfc2849.txt (added)
+++ directory/ldapstudio/trunk/ldapstudio-browser-help/resources/rfc/rfc2849.txt Thu Jan 25 15:21:17 2007
@@ -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]
+



Mime
View raw message