One document matched: draft-ietf-ldapext-authmeth-00.txt

Network Working Group                                            M. Wahl
INTERNET DRAFT                                       Critical Angle Inc.
Expire in six months                                    November 7, 1997


                      Authentication Methods for LDAP
                     <draft-ietf-ldapext-authmeth-00.txt>

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 
       <draft-ietf-asid-ldapv3-protocol-09.txt>. 

   [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
       <draft-ietf-asid-ldapv3-tls-02.txt>.

   [6] T. Diers, C. Allen, "The TLS Protocol Version 1.0", Oct. 1997,
       INTERNET DRAFT <draft-ietf-tls-protocol-04.txt>.

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