[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 rfc2829                                        
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
                   <draft-ietf-ldapext-authmeth-01.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

   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
       <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>.

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]