|< Day Day Up >|| |
The previous three models provided us with many of the elements needed to construct a directory. The information model gave us the means to define the single elements to hold our data; the naming model helped us in building a hierarchical structure with these elements; and the functional model allowed us to access these data structures and manipulate them. What is still missing is a security model showing how to secure the data in the directory. There are two major arguments in place: authentication and authorization, also called "access control" in LDAP.
The security model is very important because LDAP is a connection-oriented protocol. In a typical conversation between client and server, the client opens a connection to the server. The client asks the server to perform an action upon this connection, and the server sends the results back. It is important that both server and client are always aware of the connection. After opening the connection with the server, the client can provide the server with user credentials (e.g., userID and userPassword) to prove its identity. If the server accepts these credentials, it associates or "binds" certain access rights to these user credentials. The client maintains these access rights bound to the user credentials until it unbinds or sends additional user information to obtain different access rights.
Note that not all protocols in the application layer are connection-oriented. An example of a protocol that does not know the concept of connection is the HTTP protocol. Every request the browser makes to the Web server has no connection with the previous one. The concept of connection in an HTTP conversation has to be implemented by server-side programs, i.e., the mechanism that maintains a session is implemented over the HTTP protocol. LDAP does not need such workarounds because the protocol itself maintains the connection.
Before a client can access data on an LDAP server, two processes must take place first: authorization and authentication. These two processes are quite different from each other. This section briefly reviews the different concepts behind these processes. The focus is on authentication, since authorization is not yet covered by standards.
Authentication takes place when the client identifies itself for the server as it tries to connect. The process depends very much on the authentication mechanism used. The easiest way is to connect to the server without the need to provide an identity. To such an anonymous connection, if allowed at all, the server grants the lowest access rights. There are authentication schemes ranging from simple authentication with user and password to authentication using certificates. These certificates give the assurance to the server that the client really is who it says it is. Certificates can also assure the client about the server's identity.
Once the client has been recognized by the server, the client will have certain access rights to the data. Authorization is the process by which the server grants the correct access rights to the previously authenticated client. This means that the user can read and write data with restrictions that depend on the level of access granted. To define what each client can do, the server must maintain an access control information (ACI) file.
More so than the other models, the security model is still a work in progress, especially regarding the authorization aspect. LDAP authentication is covered by a few RFC standard specifications, as we will see in the next section. Authorization, called "access control" in LDAP parlance, is not yet covered in LDAP standards. Meanwhile LDAP (v2) did not have any support for authorization methods. LDAP (v3) has a set of recommendations expressed in RFC 2820, "Access Control Requirements for LDAP." This RFC does not, however, express any standard; its recommendations are only informational. Nevertheless, this does not mean that LDAP implementations lack for authentication or access control. Instead, in the absence of a standard, every implementation has its own method for access control. Unfortunately, these methods are incompatible with each other. So once you have identified your needs, you have to check the vendor documentation to see whether the product contains the features you wish to use.
The basic requirements for authentication in LDAP are defined in RFC 2829, "Authentication Methods for LDAP." The following is a brief list of the most important requirements:
Client authentication: Client authenticates itself against the directory server using certificates, encryption, or clear text.
Client authorization: By means of access-control mechanisms, the directory server controls what the client can request on the directory server based on the previous authentication (see next section).
Data integrity mechanisms: Guarantee that what the client sent arrives at the server and vice versa.
Snooping protection: Prevents a listener in the network from snooping using encrypted conversation.
Protection against monopolization: Limits resources to prevent a user from monopolizing the system.
Server authentication: Server authenticates itself against the client to guarantee to the client that the server is responding.
There are different levels of authentication. In the previous section (functional model), we saw the function "bind"`used for the user authentication process. Binding to the server means authenticating the user against the server. There are various methods to authenticate the client.
Authentication providing security via encryption
Authentication using encryption and certificates
The first type of authentication is "no authentication at all," also called "anonymous bind" because the server has no idea of who actually is asking for a connection. Anonymous bind is used to access publicly available data, for example a public telephone book. The server configuration determines whether anonymous access is allowed and the level of access to data for the anonymous user.
Note that the server assumes anonymous access if the client does not provide user credentials to the server. Sometimes this may not be what you really wanted. If an application uses an LDAP server for authentication, it sends userID and userPassword to the LDAP server. If the LDAP does not report an error and opens a connection, the application assumes that the authentication was successful. Unfortunately, the LDAP server does not report an error if it does not receive any user information at all, and therefore connects the user as an anonymous user. Therefore the application has to control whether the user has supplied data for userID/userPassword and, if this information is missing, should refuse the connection.
After anonymous access, the simplest authentication is the basic authentication, which is also used in other protocols like HTTP. The client simply sends the user credentials across the wire. In the case of LDAP, this means the user's distinguished name and the userPassword. Both of them are sent over the network in plain view without encryption. This method may be okay in a trusted environment, but even in an intranet environment, sending around unencrypted passwords is not a good idea. Remember the false assumption that the bad guy is always "outside."
The server looks for an attribute named "userPassword" in the entry corresponding to the distinguished name. The value of this attribute is compared with the user input. If the password matches, the connection with the LDAP server is established. If there is no match, an error message is sent and the connection dropped. Again, this is not the safest of all methods, but it could he acceptable in an intranet environment.
Although the user credentials are sent in plain ASCII text, this does not mean that you can read or write them as easily as you can with other protocols such as HTTP. Recall from Chapter 1 that LDAP messages are encoded using BER encoding. By the way, LDAP (v2) also offered the ability to encode user credentials using base-64 encoding as defined in the MIME extensions in RFC 1521.
The SSL (Secure Sockets Layer) protocol implements security mechanisms in the TCP/IP protocol stack right between the transport layer and the application layer, i.e., the layer below LDAP. SSL is based upon public-key cryptography and was developed by Netscape. The TLS 1 (Transport Layer Security) protocol was born from SSL version 3 and is documented in RFC 2246, "TLS Protocol version 1.0."
The standard requires providing TLS in the form of an extended request. From discussion of the functional model in the previous section, recall that the client — via the startTLS, an extended operation — requests the beginning of a TLS session. Recall also that a unique object identifier (OID) identifies each operation. For example, the "startTLS" operation is requested by its OID "18.104.22.168.4.1.1466.20037." The server confirms the TLS session if it supports TLS.
The TLS integration in LDAP is defined in RFC 2830, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security." Meanwhile, RFC 2246 describes the TLS protocol, and RFC 2830 describes how the TLS protocol has to be established between client and server.
The goal of the TLS protocol is to provide both data integrity and privacy. This means that the TLS protocol guarantees that data sent between two partners arrives unmodified and that the conversation is encrypted, i.e., that a person sitting between client and server can not intercept the conversation. TLS requires a reliable protocol and is based upon TCP. TLS itself comprises two different protocols, the TLS Record protocol and the TLS Handshake protocol. The function of the TLS Record Protocol is only the encapsulation of the higher protocol, the TLS Handshake protocol. The TLS Handshake protocol instead provides the security mechanisms. It allows server and client to authenticate each other and negotiate encryption protocol and cryptographic keys. The TLS Handshake protocol supports the public key mechanism.
LDAP (v2) supports a bind mechanism based on Kerberos, but it is not directly supported in LDAP (v3). By "not directly supported," we mean that it can be used as a security mechanism upon an agreement established using the SASL protocol, which is discussed in the next section. Kerberos itself is a protocol that relies upon a third authority, the authentication server. Kerberos is defined in RFC 1510, "The Kerberos Network Authentication Service (v5)." Kerberos is a security mechanism planned for use in an extremely insecure environment such as the Internet. Kerberos does not make any assumption about the integrity of the messages sent between the two communicating partners. The communication is encrypted, and both partners can be confident about the identity of the other.
While TLS or SSL involve only the two communicating partners. Kerberos needs a dedicated authentication server, which means that a third partner is involved. The client asks the authentication server for credentials. With this request, it also specifies which server it intends to speak with. The Kerberos gives to the client these requested credentials in the form of two pieces: a ticket for the server the client wants to contact and a "session key." The session key is a temporary encryption key valid for this particular session. Now the client is ready to contact the server. The server encrypts the ticket and the session key with the server's key and sends it to the server. At this point, the server and the client both know the session key. Further into the conversation, this key is used to authenticate the client or the server. This key can be used to encrypt the conversation between client and server or to exchange a further subsession key to be used for the conversation. The ticket and the session key both cannot be recycled because they are temporary and can only be used from a certain client to contact a certain server.
This mechanism is also designed to work across organizational boundaries. The client can ask an authentication server to send credentials for a conversation with a server in another organization. The context within which the partners are located is called a "realm." In this case, the client asks the authentication server for credentials for a server in another realm. The realm the client is located in is part of the client's name. The server can furthermore decide to speak only with clients within a certain realm.
The Kerberos protocol is a very stable and reliable protocol covering a most of the requirements for securing the conversation in an insecure environment. It can be used from a great number of protocols and is platform independent.
The simple authentication and security layer (SASL) is a method of providing authentication services to a connection-oriented protocol such as LADP. The SASL standard is defined in RFC 2222, "Simple Authentication and Security Layer." This standard makes it possible for a client and server to agree upon a security layer for encryption. Once the server and client are connected, they agree upon a security mechanism for the ongoing conversation. One of these mechanisms is Kerberos. At the time of this writing, a number of mechanisms are supported by SASL, including:
Anonymous, described by RFC 2245, "Anonymous SASL Mechanism"
CRAM-MD5, described by RFC 2195, "IMAP/POP AUTHorize Extension for Simple Challenge/Response"
Digest-MD5, described by RFC 2831, "Using Digest Authentication as a SASL Mechanism"
External, described by RFC 2222, "Simple Authentication and Security Layer (SASL)"; updated by RFC2444, "The One-Time-Password SASL Mechanism"
Kerberos (v4), described by RFC 2222 and RFC 2444
Kerberos (v5), described by RFC 2222 and RFC 2444
SecurID, described by RFC 2808, "The SecurID® SASL Mechanism"
Secure Remote Password, described by draft-burdis-cat-srp-sasl-07.txt, "Secure Remote Password SASL Mechanism"
S/Key, described by RFC 2222 and RFC 2444
X.509, described by draft-ietf-ldapext-x509-sasl-03.txt, "X.509 Authentication SASL Mechanism"
Although TLS and SSL are simple layers between the application protocol (LDAP in our special case) and the TCP/IP protocol, the SASL protocol has particular requirements for an application protocol. It dictates that the client open the TLS connection. The server has to answer with success or an error message. Furthermore, it requires the application protocol to put at disposal a special message for the TLS request from the client and the TLS response from the server. This is why TLS is available only in version 3 of LDAP, which includes the extended startTLS operation. The exact requirements for implementation of SASL exceed the scope of this book and can be found in RFC 2222. The implementation of SASL in LDAP is covered in RFC 2830, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security."
The TLS connection is established via the startTLS request. As the title of the RFC 2830 suggests, the standard defines TLS for version 3 of the LDAP protocol. The startTLS request is an example of an extended operation. Let us briefly review how the standard stipulates the establishment of a TLS session.
The client requests a secure connection via the extended operation startTLS. The server must answer with one of the following responses:
success: Server is ready to negotiate TLS using the Handshake protocol of TLS.
operationsError: Indicates an error in the sequence of the operation, e.g., TLS has just been established before the actual request. In other words, the server got the request for establishing TLS after TLS was already established.
protocolError: Normally means that TLS is not supported by the server. This error is also produced if the client has sent a malformed protocol data unit (PDU).
referral: If a server sends back a referral to another LDAP server, this means that the original server does not support TLS but knows an LDAP server that does.
unavailable: Server is shutting clown, or there is some problem with TLS on this server.
Once the server has sent the "success" response to the client, the negotiation of TLS can begin. The first thing both have to agree upon is the supported TLS version. The second thing is the security mechanism to use for the conversation. Both parties decide whether they accept the security level achieved. If the server or the client decides that the level is not high enough, it closes the TLS connection.
Authentication gives the server the credentials needed to let the user access the server. It also allows both the server and the client to verify the other's identity. Once the connection is made, the client and server can exchange messages that arrive intact without modification or interception by any third party.
Until now, we have spoken only of clients and servers. This is just one of many scenarios requiring a high level of security. Replication is another scenario. The topic of replication is addressed at several points later in this book. For now, it is enough to know that replication allows you to mirror one part of the directory or the entire directory on another server. If you replicate the entries from one server to another, you can also replicate the security requirements protecting the information on both servers from unauthorized clients. However, to do so, the server-to-server authentication will have to be the same as that used to authenticate clients.
Another scenario is a mechanism known as chaining. If a server contacted by a client does not hold the required information, it might use an alias or a referral to direct the client to a server holding the relevant information. However, if the server supports chaining, it can access the relevant server and then deliver the requested information directly to the client. This is another case where the server-to-server security level must be the same as that between client and server.
Look at the documentation of your server implementation to see which authentication features it supports. It may be that your implementation does not support all of the features proposed by the standard, or it may have its own extensions that are different from the standard.
Authorization — also called "access control" — is the process by which a server grants the correct access rights to a previously authenticated client. At the time of this writing, the standards do not say much about authorization. This does not mean that directory servers do not support authorization. Nearly every software vendor has a proprietary solution. The access control information (ACI) is held in an access control list (ACL). The bad news is that every server implementation has its own method of holding the ACI. At the time of this writing, OpenLDAP holds this information in the configuration files. Netscape keeps this information in the directory, which has a big advantage in that it can be inspected and updated using the LDAP protocol itself. Obviously only authenticated and authorized clients can view or update the access-control information.
Access-control information can contain the following specifications:
Data protection: You can deny or allow access to the entire tree, a subtree, or a DN.
Data access: You can define the clients who have access to the system:
Anonymous: Every user, without authentication
Authenticated users: Users that have been authenticated by the system
Self: User associated with the target entry
Distinguished name: User matching the expression in the distinguished name
Level of access: You can define access rights for the user:
Right to bind
Right to execute or compare
Right to execute search
Right to read search results
Right to modify entries
Further requirements: You can further restrict the IP numbers or host names to be serviced, the time of day service would be granted or denied, etc.
It is important to remember that, at the time of this writing, access control information and access control lists are not covered by any standard. Vendors support them in any number of ways. Because each vendor provides a unique solution, there is no guarantee of interoperability between the solutions of different vendors. You should consult the documentation shipped with the product you are using to learn the exact functionality and the exact syntax.
|< Day Day Up >|| |