HTTP/1.1 200 OK Date: Tue, 09 Apr 2002 04:43:15 GMT Server: Apache/1.3.20 (Unix) Last-Modified: Wed, 18 Mar 1998 02:31:00 GMT ETag: "2e7b28-4df1-350f31e4" Accept-Ranges: bytes Content-Length: 19953 Connection: close Content-Type: text/plain Network Working Group M. Wahl INTERNET-DRAFT Critical Angle Inc. H. Alvestrand MaXware AS Expires in six months from January 28, 1998 Authentication Methods for LDAP 1. Status of this Memo This document is an Internet-Draft. Internet-Drafts are working docu- ments 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 learn the current status of any Internet-Draft, please check the ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or ftp.isi.edu (US West Coast). 2. Abstract This document specifies particular combinations of SASL [2] mechanisms and extensions which are required and recommended in LDAP [1] implementations. 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]. 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 et al. Authentication Methods for LDAP [Page 1] INTERNET-DRAFT draft-ietf-ldapext-authmeth-01.txt January 1998 2. Threats to an LDAP directory The basic threats to the LDAP service are: (1) Unauthorized access to data via data-fetching operations, (2) Unauthorized access to data by monitoring others' access, (3) Unauthorized modification of data, (4) Unauthorized modification of configuration, (5) Unauthorized use of resources (denial of service), and (6) Spoofing of directory: Tricking a client into believing that information came from the directory when in fact it did not. The LDAP protocol suite can be protected with the following security mechanisms: (1) Client authentication by means of the SASL mechanism set, possibly backed by the TLS credentials exchange mechanism, (2) Client authorization by means of access control based on the authenticated identity, (3) Snoop protection by means of the TLS protocol, (4) Resource limitation by means of administrative limits on service controls, and (5) Server authentication by means of the TLS protocol. At the moment, imposition of access controls is done by means outside the scope of the LDAP protocol. 4. Deployment scenarios The following scenarios make sense for LDAP, and have vastly 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) (1) A read-only directory, containing no sensitive data, accessible to "anyone". This directory requires no security functions except the service limits. Wahl et al. Authentication Methods for LDAP [Page 2] INTERNET-DRAFT draft-ietf-ldapext-authmeth-01.txt January 1998 (2) A read-only directory containing no sensitive data; read access is granted based on identity. This scenario requires a secure authentication function. TCP connection hijacking is not currently a problem. (3) A read-write directory, containing no sensitive data; read access is available to "anyone", update access to properly authorized persons. This scenario requires a secure authentication function. TCP connection hijacking is not currently a problem. (4) A directory containing sensitive data. This scenario session confidentiality protection AND secure authentication. This document does not describe the requirements for use of LDAP in physically protected networks; this is concerned with LDAP used on the Internet. 5. Choice of mandatory 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. 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. At the moment, only implementations using public key cryptography satisfy the requirement that it be useless for faking authentication. Therefore, the following mandates are in place: (1) For a read-only, public directory, anonymous authentication, described in section 6, can be used. (2) Implementations MUST support password-based authentication using CRAM-MD5, as described in section 7.1. Wahl et al. Authentication Methods for LDAP [Page 3] INTERNET-DRAFT draft-ietf-ldapext-authmeth-01.txt January 1998 (3) For a directory needing session protection and authentication, Start TLS with the SASL EXTERNAL mechanism is to be used. Implementations SHOULD support authentication with a password as described in section 7.2, and SHOULD support authentication with a certificate as described in section 8.1. 6. Anonymous authentication Anonymous authentication is suitable for users who do not intend to modify directory entries and do not require access to protected attributes or entries. LDAP implementations MUST support anonymous authentication, as defined in section 6.1. While there MAY be access control restrictions to prevent access to directory entries, an LDAP server MUST allow an anonymously-bound client to retrieve the supportedSASLMechanisms attribute of the root DSE. 6.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. 6.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 and does not present a certificate during TLS negotiation, then the client is anonymously authenticated. 7. Password-based authentication LDAP implementations MUST support authentication with a password using the CRAM-MD5 mechanism for password protection, as defined in section 7.1. LDAP implementations SHOULD support authentication with the "simple" password choice when the connection is protected against eavesdropping using TLS, as defined in section 7.2. Wahl et al. Authentication Methods for LDAP [Page 4] INTERNET-DRAFT draft-ietf-ldapext-authmeth-01.txt January 1998 7.1. CRAM-MD5 authentication A user who has a directory entry containing a userPassword attribute may authenticate to the directory by performing a protected password bind sequence based on the CRAM-MD5 mechanism [4]. 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 "CRAM-MD5" is present as a value of this attribute. In the first stage of authentication, the client sends a bind request in which the version number is 3, the name field is the name of the user's entry, the authentication choice is sasl, the sasl mechanism name is "CRAM-MD5", and the credentials are absent. The client then waits for a response from the server to this request. The server shall generate a challenge and return a bind response in which the resultCode is saslBindInProgress, and the serverSaslCreds field is present. The contents of the serverSaslCreds string is the challenge, which is not base64 encoded. An example challenge is "<1896.697170952@postoffice.reston.mci.net>". Note that in this stage of the mechanism, the server need not access the user's entry. The server will save the challenge internally, associated with the connection, until the next stage of the bind operation is completed. The challenge string will not reused, however. Upon receipt of the challenge, the client will generate the response digest value, which is a string of 32 hexadecimal digits. An example digest derived from the above challenge and the password "tanstaaftanstaaf" is "b913a602c7eda7a495b4e6e7334d3890". The client will send a bind request, with a different message id, in which the version number is 3, the name field is the name of the user's entry, the authentication choice is sasl, the sasl mechanism name is "CRAM-MD5", and the credentials field contains a concatenation of the name of the user's entry, a space character (ASCII 32), and the digest string. The client then will waits for another response from the server. The server will then, for each value of the userPassword attribute in the named user's entry, generate the digest value itself, and compare the result with the client's presented digest. If there is a match, then the server will respond with resultCode success, otherwise the server will respond with resultCode invalidCredentials. The serverSaslCreds field will be absent. Wahl et al. Authentication Methods for LDAP [Page 5] INTERNET-DRAFT draft-ietf-ldapext-authmeth-01.txt January 1998 If the client does not complete the SASL negotiation, the server MUST delete the challenge from memory, as challenge strings MUST never be used twice. A client MUST NOT send more than one bind request containing response digest values in which the same challenge string was used. If a client wishes to change authentication, it MUST start from the beginning and request a new challenge. 7.2. "simple" authentication choice under encryption A user who has a directory entry containing a userPassword attribute can 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 cipher algorithm. The following are NOT permitted: TLS_NULL_WITH_NULL_NULL TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA The RECOMMENDED ciphersuite is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. 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. 8. Certificate-based authentication LDAP implementations SHOULD support authentication via a client certificate in TLS, as defined in section 8.1. Wahl et al. Authentication Methods for LDAP [Page 6] INTERNET-DRAFT draft-ietf-ldapext-authmeth-01.txt January 1998 8.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. 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. 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 cipher algorithm. The following are NOT permitted: TLS_NULL_WITH_NULL_NULL TLS_RSA_WITH_NULL_MD5 TLS_RSA_WITH_NULL_SHA The RECOMMENDED ciphersuite is TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. The server MUST verify that the client's certificate is valid, issued by a known CA, and that none of the certificates on the client's certificate chain are invalid or revoked. Following the successful completion of TLS negotiation, the client MUST send an LDAP bind request with the SASL "EXTERNAL" mechanism. The format of this bind request and the server's behavior is defined in section 6.2 of [5]. If the server receives a bind request with the EXTERNAL SASL mechanism name and TLS has not been negotiated, it SHOULD return a resultCode of invalidCredentials. 9. Limited Use 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. Wahl et al. Authentication Methods for LDAP [Page 7] INTERNET-DRAFT draft-ietf-ldapext-authmeth-01.txt January 1998 The following SASL-based mechanisms are not considered in this document: KERBEROS_V4, GSSAPI and SKEY. 10. 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 DIT 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 CRAM-MD5 mechanism can be found in [4], and security considerations relating to the EXTERNAL mechanism to negotiate TLS can be found in [2], [5] and [6]. 11. Acknowledgements This document is a product of the LDAPEXT Working Group of the IETF. The contributions of its members is greatly appreciated. 12. 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] J. Klensin, R. Catoe, P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response", Sep. 1997, RFC 2195. [5] J. Hodges, RL Morgan, M. Wahl, "LDAPv3 Extension for Transport Layer Security", Aug. 1997, INTERNET DRAFT . [6] T. Diers, C. Allen, "The TLS Protocol Version 1.0", Oct. 1997, INTERNET DRAFT . Wahl et al. Authentication Methods for LDAP [Page 8] INTERNET-DRAFT draft-ietf-ldapext-authmeth-01.txt January 1998 13. Authors Address Mark Wahl Critical Angle Inc. 4815 West Braker Lane #502-385 Austin, TX 78759 USA EMail: M.Wahl@critical-angle.com Harald Tveit Alvestrand Harald.Alvestrand@maxware.no 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 et al. Authentication Methods for LDAP [Page 9]