Access Control and Security Layers

Not all directories provide a read-only white-pages service that should be publicly available. Access might be limited to subscribers of the service or only available on a pay-per-view basis, in which case appropriate accounting mechanisms would have to be in place. The data contained in the directory could be of a sensitive nature so that access by non-authorized parties would not be allowed.

The security model for directory services relies on the fact that the protocols, which are used to access the directory, are connection-oriented. It is assumed, that peer entities do not change after a connection has been established. To ensure this in an insecure environment, security layers have to be deployed. All operations, which are initiated over a connection, can rely on data that was exchanged earlier. This is used to implement access control mechanisms. At the beginning of a connection the client's identity is established during the authentication stage. For each subsequent operation requested by the client, the server checks whether the client is authorized to do so.

Authentication

Authentication is the process of verifying that a peer entity in a connection is genuine. For use in computer systems the identity of a peer entity is generally represented by an alphanumeric string of some form, for example, DNs, fully qualified domain names, user ids or social security numbers. To assert the claimed identity, credentials are passed between the communication parties. [48]

The following section presents different authentication mechanisms grouped by the type of credentials and their underlying cryptographic properties. All mechanisms described here deal with client to server authentication.

Cryptographic background

One-way-hash-functions

A message digest--or secure hash--is the result of a so called one-way-hash-function. These functions have the property that it is ``computationally infeasible to find a message which corresponds to a given message digest, or to find two different messages which produce the same message digest'' [72]. In other words, hash = f (password ) can be computed easily but not the inverse password = f^-1(hash).

Symmetric cryptosystems

In symmetric cryptosystems, the same key is used for encrypting and decrypting a message. Such a key must be kept secret between the communications parties, as its disclosure would reveal any transmission encrypted with this key. Symmetric cryptosystems are therefore also called secret-key cryptosystems.

Two problems exist with the practical use of secret-key cryptosystems. First, keys have to be transferred over a secure channel. This brings up the problem of initially establishing a secure channel. Secondly, a separate key has to be agreed upon for each pair or communication peers. In a network with n participants, this would require (n(n - 1))/2 keys to be generated and distributed.

Asymmetric cryptosystems

The concept of asymmetric cryptosystems--also known as public-key cryptosystems (PKCS)--was first published in [9]. It builds on the idea that keys are used in pairs. Every participant in such a system has two keys. A message encrypted with one of the keys can only be decrypted with the other one. In asymmetric crypto systems one of the keys can be openly distributed--the public key. The matching private key must be kept secret. For such a system to provide strong security, it is vital that computing the private from the public key is next to impossible, i.e. very time consuming. If a message is to be sent securely, it is encrypted with the addressee's public key. Then only the recipient that has the matching private key can read it.

Public-Key algorithms are slower than symmetric algorithms by orders of magnitude. In data encryption applications, a hybrid approach is therefore taken. A random key--the session key--is generated and encrypted with the asymmetric algorithm. The actual message is then encrypted with a fast symmetric algorithm using the session key.

In asymmetric cryptosystems, keys do not have to be transferred over secure channels since public keys are openly available. However, it remains to be ensured, that a public key really belongs to its apparent owner. This is accomplished by a certificate. In a certificate, a trusted third party certifies the link between public key and its owner. Certificates make use of the second application of asymmetric cryptosystems--signing. To sign a message, a digest of the message is generated and encrypted with the sender's private key. The recipient receives both the original message and the encrypted digest. He then decrypts the digest using the sender's public key and compares it to the digest generated from the message. If these values match, it is ensured that the message was not changed during transit (integrity protection) and actually comes from the designated sender (non-repudiation).

Authentication Methods

Anonymous

In many applications, it is not necessary--and sometimes not desirable--that clients authenticate themselves to the server. This is usually true for read access to public data. Since the data is public, there is no need to restrict access to specific users. It should be in the service provider's interest to fashion the access for customers as easy as possible. Any uncalled for efforts might drive the customer elsewhere. From the client's perspective, not giving away too much information about the user helps in upholding privacy. This prevents the server's operator from building detailed customer profiles.

If no authentication is performed, the client is said to be ``anonymous''. This is also the initial state for the client, after a connection has been opened to the server.

Plain Text Passwords

The authentication protocol with plain text passwords works as follows:

1. The server asks the client for username and password.
2. The client responds with username and password.
3. The host compares the password with the value on record for the specified username.

The major disadvantage of plain text passwords is that they are easily to compromise. Anyone who can physically eavesdrop on the communication between client and server will learn the password (and the authentication identifier). Once obtained, the credentials can be reused until the password is changed. The attacker might even change the password himself and thus lockout its original holder.

Great care must also be taken to protect the passwords stored on the server. Anybody who is able to read these secrets will get instantaneous access to all accounts on the system. As the server must only be able to verify that a password is correct, there is no need to store the actual passwords themselves. To accomplish this, only hashes of passwords are stored. The initial plain text password protocol mentioned above is thus changed in step 3:

3.a)

The host applies the hash function to the transmitted password -and-

3.b)

compares the result to the stored hash value.

Unix systems make use of the crypt(3) function to store password hashes in the system wide /etc/passwd file. crypt(3) is a variation of the DES [73] algorithm, where a known plaintext is encrypted with a key generated from the user's password [84]. The resulting cipher text is the output of the hash function. Due to ever-increasing computing power, the crypt(3) has become susceptible to brute-force attacks^4.1 or a refined form thereof--the dictionary attack. In a dictionary attack, not every possible combination of characters is tried out. Instead only common words that are often chosen as passwords and their variations are considered. To strengthen security one needs to make it difficult for a lot of passwords to be tried in a short time. This can be achieved by the following measures:

Restrict access to hashed passwords. In Unix systems the password hashes are not now stored in the world-readable /etc/passwd file but are located in a so-called shadow file that is only readable by the super-user.

Enforce the use of longer and more complex passwords. The key space of 8-character alphanumeric password is 18 million times the size of 5-character lower-case passwords.

Employ computationally more expensive hash algorithms like MD5 [81] or
SHA-1 [72].

Use salted hash functions: a random string is used as an additional parameter to the hash function. This reduces the probability of attacks with pre-build dictionaries. In such a scenario, the attacker builds a database of inputs and corresponding hash values. Now if a hash value becomes known, only a database lookup is needed to find the matching password. However, with every bit of additional input from the salt, the size of such a database would double. The standard Unix crypt system uses 12 bits of salt, which would require 4096 combinations for each password.

However, all these precautions are useless when plain text passwords can easily be obtained by wiretapping. Their use on the Internet without additional protection mechanism is therefore strongly discouraged.

Challenge-Response Mechanisms

A server task is to verify that a client knows the shared secret; the secret itself need not necessarily be transmitted to prove this. Such a protocol can be outlined as follows:

1. The server generates a random string and issues it as challenge to the client.
2. The client computes a response from the challenge using a value derived from its password and sends the response along with its authentication identifier to the server.
3. The server performs the same calculation and compares its result to the response sent by the client.

By choosing a new challenge every time, the protocol prohibits replay attacks. Instead of the actual password, the derived value mentioned in step 2 is stored on the server. As such a value is password equivalent, i.e. its knowledge is sufficient to authenticate, it still must be adequately protected.

Examples for challenge-response mechanisms include CRAM-MD5 [51] and DIGEST-MD5 [56]. In contrast to CRAM-MD5, DIGEST-MD5 prevents chosen plaintext attacks^4.2.

Kerberos

Kerberos [69] is a network authentication protocol that provides strong authentication for client/server environments. It makes use of symmetric encryption for authentication purposes [74]. Each participant in the system--a principal in Kerberos terms--shares a secret key with the central Key Distribution Centre (KDC). The KDC actually consists of two components: the Authentication Service (AS) and the Ticket-Granting Service (TGS).

The credential in Kerberos is the ticket. To gain access to a service, the client requests a Service Ticket from the TGS. The client can then prove its identity to the service with this ticket. However, the client must first establish its identity with the TGS before any Service Tickets will be issued. To this end, the client authenticates with the AS and receives an initial ticket--the Ticket-Granting Ticket (TGT). The TGT is then used in all subsequent requests to the TGS. This procedure makes Kerberos a Single Sign-On protocol. The user only has to provide his password once when authenticating to the AS. To prevent misuse of tickets, they expire after a defined period^4.3. [58]

Version 5 [52] is the current version of the Kerberos standard.^4.4 Applications usually do not call Kerberos functions directly. Instead they use the Generic Security Service Application Program Interface (GSSAPI) [60]. GSSAPI is a security framework that abstracts from underlying protocols. A GSSAPI mechanism that uses Kerberos 5 as underlying protocol (GSS-KRB5) has been defined in [59].

X.509

X.509 [40] was originally designed as authentication framework for X.500 directories. The strong authentication method defined therein makes use of public key cryptosystems and is now widely used for secure email (S/MIME) and secure connections (SSL and TLS). The trusted third party is the Certification Authority (CA). The CA is responsible for creating certificates--the credentials in X.509. A certificate contains a public key, the distinguished name of the entity that is to be associated with this key, and the CA's distinguished name. These elements are then signed by the CA with its private key, thus making the certificate unforgeable.

Authorization

Authorization is the process of determining, whether the requested access to a resource may be granted. The rules--often called Access Control Lists (ACL)--that govern this process are expressed in terms of Access Control Factors (ACF). Common ACFs in the LDAP context are [93]:

The authentication method.

The authorization identity.

The kind of requested operation (e.g. search or modify).

The entries and attributes affected by the operation.

Factors outside the LDAP protocol itself, like source IP-address or encryption strength.

Generally, the authorization identity is equal to authentication identity. However, this does not necessarily have to be the case. A proxy policy may allow certain users to act on behalf of others. They authenticate as themselves but then take the role of another user for the purpose of authorization.

Security Layers

Security layers protect data on its way between the communication peers from

1. being altered in transit. This is known as integrity protection.
2. being overheard by an unauthorized person. This in known as privacy protection.

Security layers are commonly provided at the transport layer. The relevant standards in this field are the Secure Socket Layer (SSL) [13] and its successor, Transport Layer Security (TLS) [8]. But also Kerberos and SASL include the ability to establish a security layer. With IPsec a standard has emerged, which offers support for a security layer at the network layer of the Internet Protocol.

LDAP over SSL (LDAPS^4.5) is available in most mainstream products. Support for TLS via the StartTLS extended request [21] is so far only available in OpenLDAP and MessagingDirect products. (See also Figure )

SASL

The Simple Authentication and Security Layer (SASL) provides ``a method for adding authentication support to connection-based protocols'' [71]. SASL allows application layer protocols to make use of different authentication mechanisms. To implement SASL, a protocol needs to define an operation by which a user can authenticate himself to a server. This operation must include the name of the authentication mechanism to use and may include an authorization identifier if it is different from the authentication identifier.

Often some way is provided, by which a client can determine which mechanisms the server supports. In LDAP, these can be requested by retrieving the ``supportedSaslMechanisms'' attribute from the server's rootDSE.

SASL mechanisms that have been defined include:

ANONYMOUS (defined in [76], see also )

PLAIN (defined in [77], see also )

DIGEST-MD5 (defined in [56], see also )

GSSAPI (defined in [71], see also )

EXTERNAL (defined in [71]). By using the EXTERNAL mechanism, the authentication identity is determined form an external source, e.g. from certificates that have been exchanged during the negotiation of a security layer with SSL or TLS.

Authentication Methods for LDAP

[93] identifies three levels of protection and their appropriate authentication mechanisms:

Public read-only directories do not require any authentication, i.e. anonymous authentication is sufficient.

For connections that require authentication, the DIGEST-MD5 mechanism must be used to protect the password from passive eavesdropping attacks.

If, in addition to the password, the whole session is to be protected, the use of TLS in combination with plain-text passwords or the SASL EXTERNAL mechanism is recommended. TLS also provides protection against active man-in-the-middle attacks.