Messaging and Directory Server software used around the world in the Government, Military, Aviation and Commercial sectors.

isode.com / whitepapers /

Why Strong Authentication for Directory

Purpose

LDAP and the X.500 directory protocols can all use strong authentication based on X.509 PKI (Public Key Infrastructure). This paper looks at the benefits and issues in using strong authentication for directory. It considers security threats to directory and looks at how strong authentication can be used to address these threats. It also looks at administrative benefits and drawbacks.

This paper argues that strong authentication should used wherever possible for server to server communication, and for administrator access.

PKI and Strong Authentication

A companion paper "The Security and Administrative Benefits of using X.509 PKI based Strong Authentication" discusses general issues on the use of strong authentication. It shows that in many situations there can be significant security and administrative benefits to using strong authentication. It is assumed that the reader has read this companion paper.

How Directories are Used

The security threats to a directory service will depend significantly on how the directory service is used. Threats need to be considered in terms of the users of the directory service. Although directories can be used for many things, there are common patterns for many deployments of directory. The following model of directory usage applies to many Isode customers, and seems a good basis for analysing security threats.

1. Directory deployments usually involve more than one server, with replication and often communication between servers.
2. Read access is often anonymous.
3. Data stored in directory is not generally access restricted or particularly sensitive. This is reflected in anonymous access.
4. Critical data is generally managed centrally. Users may be able to update non-critical data.
5. Access to all or large portions of the data in a directory is undesirable (e.g., a university is happy to have email address lookup of one student, but not to give access to a list of all email addresses).
6. Directory is often used to support critical infrastructure services, such as email or PKI. Incorrect behaviour of the directory is likely to cause operational problems with these supporting services.

Directory Security Threats

There are a number of basic threats to a directory of this nature that must be considered.

1. Denial of service attacks on the directory or infrastructure supporting a directory server can cause critical problems to applications relying on the directory.
2. Applications which attempt to dump, or to extract excessive amounts of data from the directory.
3. Malicious applications which attempt to masquerade as a directory server, either to clients or to other co-operating directories in a multi-server configuration.
4. Client applications making malicious updates to data stored in the directory which could cause critical disruption to services relying on that data.

These threats are severe. The level of work taken to protect against these threats will depend upon on the severity of impact, how strongly motivated potential attackers are to make attacks against the system, and other measures in place to prevent such attacks such as restriction on physical access to networks.

While the threats may be countered using a variety of techniques, strong authentication provides a relatively straightforward way to counter or eliminate certain attacks, and so should be considered as playing a key role in securing a directory deployment.

Protection Mechanisms not related to Authentication

There are some protection mechanisms that can be applied to protect against these threats which are not directly related to authentication. In particular:

1. Administrative size limits on searching can be set in order to protect the directory from "dumping data".
2. To prevent very general filters such as "aa*", to protect against systematic dumping.
3. Using multiple replicated servers will help protect against denial of service attacks directed at a single server.

Strong Authentication between Servers

Agreements between co-operating directory servers require that some form of authentication be used in order that they trust one another.

Without strong authentication, X.500 DSP (Directory System Protocol) and X.500 DISP (Directory Information Shadowing Protocol) require the exchange of plain passwords as a means of authentication. Unless access to the network is very tightly controlled, such passwords can be intercepted, in which case security is compromised. Specific threats that may result from such a compromise include:

1. By spoofing (masquerading as) a DISP replication consumer, an attacker can gain access to significant amounts of data.
2. By spoofing a DISP replication supplier, an attacker could corrupt or destroy data in the consumer directory server.
3. By spoofing a DSP chaining initiator, an attacker could make malicious updates to the directory being chained to.

When using strong authentication, each server has an X.509 certificate, which can only be used in conjunction with a corresponding private key. Having configured a server with a certificate and key, no transmission of passwords is required, and so no sensitive data is exchanged between servers
until each has been able to verify the other's identity using the certificates.

There may be other reasons which may justify a decision to use strong authentication:

1. If there are many agreements to be configured, administration can be more straightfoward (no need to manage passwords)
2. If strong authentication setup is very easy, this in itself provides an incentive compared to alternatives.
3. If strong authentication is required for a specific reason (such as interoperability with a directory which mandates it)

In summary, strong authentication significantly increases protection against the threat of attacks, as well as offering the benefit of more straightfoward administration.

Administrator Access

A directory administrator has the ability to update data in the directory, and so an attacker spoofing an administrator could cause critical disruption by making malicious updates. Using plain password authentication for administrator access should therefore be avoided. Better options are:

1. Use LDAP with a hashed password mechanism, and plain password held in the directory
2. Use LDAP in conjunction with TLS to provide data confidentiality.
3. Use strong authentication with either DAP or LDAP.

Strong authentication has the best security characteristics against this threat. It can also be used to protect against server spoofing, as described in the next section.

End User and Application Access

Handing private key installation and certification of end users is likely to be administratively inconvenient in many deployments. Given the nature of normal access, client authentication is typically not a major requirement, which means that there is a powerful administrative argument against using strong authentication for this function: anonymous access will often be appropriate.

In cases where critical use is made of the information returned from a directory (e.g., to address or route email), it is conceivable that an attacker might spoof a directory server and return malicious information. Strong authentication can be used to overcome this threat, and carries a relatively low administrative overhead (since only the server needs to be authenticated).

Where a user updates personal attributes in the directory, use of LDAP over TLS with password authentication is a good practical approach. This provides reasonable security, and integrates easily with a Web based interface.

Summary and Conclusions

There is a very clear case made in this paper for using strong authentication, both for security and administrative reasons. This is a priority for server/server communication and for administrator access. Client authentication is generally inconvenient for end user and application access, but in some situations use of strong server authentication is desirable.