Network Working Group M. Wahl INTERNET DRAFT Critical Angle Inc. Expire in six months November 7, 1997 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 LDAP version 3 [1] uses the SASL [2] framework for exchanging authentication information between the client and server. This document specifies particular SASL mechanisms which are recommended for use in the LDAP protocol. Two means of authentication are provided, based on password hashing and public/private keys. 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. Anonymous authentication Anonymous authentication is suitable for users which do not intend to modify directory entries and do not require access to protected attributes or entries. 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. As LDAP includes a native anonymous authentication mechanism already widely used, the "ANONYMOUS" SASL mechanism is not used with LDAP. Wahl Recommended Authentication Methods for LDAP Page 1 INTERNET-DRAFT draft-ietf-ldapext-authmeth-00.txt Nov. 1997 4. Password-based 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. 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 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. 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. Wahl Recommended Authentication Methods for LDAP Page 2 INTERNET-DRAFT draft-ietf-ldapext-authmeth-00.txt Nov. 1997 4.1. "simple" authentication choice The LDAP "simple" authentication choice is present for compatibility with existing applications. It is suitable for intranet environments where the underlying network service is secured against eavesdropping. It is not suitable for authentication on the Internet where there is no network or transport layer confidentiality, or the underlying security service does not provide sufficient protection against decryption by eavesdroppers (e.g. 40 bit DES). The "PLAIN" SASL mechanism is not used, as LDAP already provides equivalent functionality. 5. Certificate-based authentication 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 must 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. The server MUST verify that the client's certificate is valid, issued by a known CA, and not on the CA's current revocation list. Following the successful completion of TLS negotiation, the client will send an LDAP bind request. The version number is 3, the name field is either the empty string or the name of the user's entry, the authentication choice is sasl, the sasl mechanism name is "EXTERNAL", and the credentials field is empty. The client will then wait for the response from the server. The server will verify that the name field of the bind request, if not empty, matches the subject field of the client's certificate, and that there is an entry in the directory identified by this name of an object class strongAuthenticationUser. If this is correct, the server will respond with the resultCode success, otherwise it will respond with the result code invalidCredentials. 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. Wahl Recommended Authentication Methods for LDAP Page 3 INTERNET-DRAFT draft-ietf-ldapext-authmeth-00.txt Nov. 1997 6. Limited Use The following SASL-based authentication methods are not considered in this document: KERBEROS_V4, GSSAPI and SKEY. 7. Security Considerations 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 to initiate 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]. 8. Bibliography [1] M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)", Nov. 1997, INTERNET DRAFT . [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 . 9. Authors Address Mark Wahl Critical Angle Inc. 4815 West Braker Lane #502-385 Austin, TX 78759 USA EMail: M.Wahl@critical-angle.com Wahl Recommended Authentication Methods for LDAP Page 4