--- /dev/null
+
+Network Working Group M. Wahl
+INTERNET-DRAFT Innosoft International, Inc.
+ H. Alvestrand
+ MaXware AS
+ J. Hodges
+ Stanford University
+ RL "Bob" Morgan
+ Stanford University
+Expires in six months from June 21, 1999
+
+
+ Authentication Methods for LDAP
+ <draft-ietf-ldapext-authmeth-04.txt>
+
+1. Status of this Memo
+
+ This document is an Internet-Draft. Internet-Drafts are working
+ documents of the Internet Engineering Task Force (IETF), its
+ areas, and its working groups. Note that other groups may also
+ distribute working documents as Internet-Drafts.
+
+ Internet-Drafts are draft documents valid for a maximum of six
+ months and may be updated, replaced, or obsoleted by other
+ documents at any time. It is inappropriate to use Internet-Drafts
+ as reference material or to cite them other than as "work in
+ progress."
+
+ To view the entire list of current Internet-Drafts, please check
+ the "1id-abstracts.txt" listing contained in the Internet-Drafts
+ Shadow Directories on ftp.is.co.za (Africa), ftp.nordu.net
+ (Northern Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au
+ (Pacific Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu
+ (US West Coast).
+
+2. Abstract
+
+ This document specifies particular combinations of security
+ mechanisms which are required and recommended in LDAP [1]
+ implementations.
+
+3. 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.
+
+
+
+Wahl, Alvestrand, Hodges, Morgan Page 1
+\f
+INTERNET-DRAFT Authentication Methods for LDAP June 1999
+
+ Basic threats to an LDAP directory service include:
+
+ (1) Unauthorized access to data via data-fetching operations,
+
+ (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, Alvestrand, Hodges, Morgan Page 2
+\f
+INTERNET-DRAFT Authentication Methods for LDAP June 1999
+
+ 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].
+
+4. 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.
+
+5. 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, Alvestrand, Hodges, Morgan Page 3
+\f
+INTERNET-DRAFT Authentication Methods for LDAP June 1999
+
+5.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.
+
+5.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.
+
+5.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.
+
+5.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.
+
+Wahl, Alvestrand, Hodges, Morgan Page 4
+\f
+INTERNET-DRAFT Authentication Methods for LDAP June 1999
+
+ 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.
+
+6. 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 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 7, can be used.
+
+
+
+
+Wahl, Alvestrand, Hodges, Morgan Page 5
+\f
+INTERNET-DRAFT Authentication Methods for LDAP June 1999
+
+ (2) Implementations providing password-based authenticated access
+ MUST support authentication using Digest, as described in
+ section 8.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, 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 8.2, and SHOULD support authentication with a
+ certificate as described in section 9.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 negotated, 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.
+
+7. 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 7.1.
+
+ LDAP implementations MAY support anonymous authentication with TLS,
+ as defined in section 7.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.
+
+
+
+Wahl, Alvestrand, Hodges, Morgan Page 6
+\f
+INTERNET-DRAFT Authentication Methods for LDAP June 1999
+
+ 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.
+
+7.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.
+
+7.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 12.
+
+ 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.
+
+8. Password-based authentication
+
+ LDAP implementations MUST support authentication with a password using
+ the DIGEST-MD5 mechanism for password protection, as defined in section
+ 8.1.
+
+ LDAP implementations SHOULD support authentication with the "simple"
+ password choice when the connection is protected against eavesdropping
+ using TLS, as defined in section 8.2.
+
+8.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.
+
+Wahl, Alvestrand, Hodges, Morgan Page 7
+\f
+INTERNET-DRAFT Authentication Methods for LDAP June 1999
+
+ 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 mesage 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 crendentials 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.
+
+8.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 12.
+
+ 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.
+
+
+
+
+
+Wahl, Alvestrand, Hodges, Morgan Page 8
+\f
+INTERNET-DRAFT Authentication Methods for LDAP June 1999
+
+8.3. Other authentication choices with TLS
+
+ It is also possible to perform a SASL authentication exchange of
+ passwords following the negotiation of TLS. In this case the
+ client and server need not negotiate a ciphersuite which provides
+ confidentiality if the only service required is data integrity.
+
+9. Certificate-based authentication
+
+ LDAP implementations SHOULD support authentication via a client
+ certificate in TLS, as defined in section 9.1.
+
+9.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 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 it 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 12.
+
+ 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.
+
+Wahl, Alvestrand, Hodges, Morgan Page 9
+\f
+INTERNET-DRAFT Authentication Methods for LDAP June 1999
+
+10. 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 a 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.
+
+ 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 authentication identity and
+ authorization identity, as well as TLS connection, which were in
+ effect prior to making the Bind request, MUST remain in force.
+
+11. 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
+
+
+Wahl, Alvestrand, Hodges, Morgan Page 10
+\f
+INTERNET-DRAFT Authentication Methods for LDAP June 1999
+
+ ; 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.
+
+ 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.
+
+12. 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
+
+
+
+Wahl, Alvestrand, Hodges, Morgan Page 11
+\f
+INTERNET-DRAFT Authentication Methods for LDAP June 1999
+
+ 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:
+
+ 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.
+
+13. 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.
+
+14. 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
+ EXTERNAL mechanism to negotiate TLS can be found in [2], [5]
+ and [6].
+
+15. Acknowledgements
+
+ This document is a product of the LDAPEXT Working Group of the
+ IETF. The contributions of its members is greatly appreciated.
+
+
+
+
+
+Wahl, Alvestrand, Hodges, Morgan Page 12
+\f
+INTERNET-DRAFT Authentication Methods for LDAP June 1999
+
+16. Bibliography
+
+ [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access
+ Protocol (v3)", Dec. 1997, RFC 2251.
+
+ [2] J. Myers, "Simple Authentication and Security Layer (SASL)",
+ Oct. 1997, RFC 2222.
+
+ [3] S. Bradner, "Key words for use in RFCs to Indicate Requirement
+ Levels", RFC 2119.
+
+ [4] P. Leach, C. Newman, "Using Digest Authentication as a SASL
+ Mechanism", INTERNET DRAFT <draft-leach-digest-sasl-00.txt>.
+
+ [5] J. Hodges, RL Morgan, M. Wahl, "LDAPv3 Extension for Transport
+ Layer Security", Oct. 1998, INTERNET DRAFT
+ <draft-ietf-ldapext-ldapv3-tls-03.txt>.
+
+ [6] T. Diers, C. Allen, "The TLS Protocol Version 1.0", Jan. 1999,
+ RFC 2246.
+
+ [7] D. Crocker, Ed., P. Overell, "Augmented BNF for Syntax
+ Specifications: ABNF", RFC 2234.
+
+ [8] S. Kent, R. Atkinson, "Security Architecture for the Internet
+ Protocol", Nov. 1998, RFC 2401.
+
+17. Authors Address
+
+ Mark Wahl
+ Innosoft International, Inc.
+ 8911 Capital of Texas Hwy, Suite 4140
+ Austin, TX 78759
+ USA
+ Phone: +1 512 231 1600
+ EMail: Mark.Wahl@innosoft.com
+
+ Harald Tveit Alvestrand
+ EMail: Harald.Alvestrand@maxware.no
+
+ Jeff Hodges
+ Computing & Communication Services
+ Stanford University
+ Pine Hall
+ 241 Panama Street
+ Stanford, CA 94305-4122
+ USA
+ Phone: +1-650-723-2452
+ EMail: Jeff.Hodges@Stanford.edu
+
+
+
+Wahl, Alvestrand, Hodges, Morgan Page 13
+\f
+INTERNET-DRAFT Authentication Methods for LDAP June 1999
+
+ RL "Bob" Morgan
+ Computing & Communication Services
+ Stanford University
+ Pine Hall
+ 241 Panama Street
+ Stanford, CA 94305-4122
+ USA
+ Phone: +1-650-723-9711
+ EMail: Bob.Morgan@Stanford.edu
+
+Full Copyright Statement
+
+ Copyright (C) The Internet Society (1998). 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.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Wahl, Alvestrand, Hodges, Morgan Page 14
+
projects / openldap / commitdiff