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]
