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

isode.com / whitepapers /

Directory Signed Operations

Purpose

Directory Signed Operations are often requested or mandated as a part of Military ACP 133 Directory or other directory services with high security requirements. This paper explains what directory signed operations are, the benefits they provide, and situations where it makes sense to require their use.

What Are Directory Signed Operations?

Directory Signed Operations are a part of the X.500 Directory Standard that applies digital signatures to individual directory operations, based on X.509 PKI (Public Key Infrastructure). Directory signed operations provide additional security by applying an X.509 digital signature to individual directory operations and to the results returned.

Signed operations are generally used in conjunction with Strong Authentication, described in the Isode white paper "Why Strong Authentication for Directory?", and add further security benefits to the peer authentication services described in this white paper.

Client Access

The basic client service of signed operations is illustrated above. A directory client has connected to a directory server using X.500 DAP (Directory Access Protocol). This connection will also be using strong authentication between client and server.

The client will issue a directory operation, such as "Read" or "Add Entry". This will be done by use of a directory "operation" PDU (Protocol Data Unit) that will be sent to the server. When signed operations are being used, a digital signature of this PDU signed by the directory client will be sent along with the PDU. This signature does three things:

1. Authentication. It provides verification to the server, that the directory client has validated the directory operation.
2. Integrity. It provides a check on data integrity, so that the server can be confident that the operation has not been tampered with.
3. Non-repudiation. It can give subsequent proof of the activity, which means that a third party can subsequently use the digital signature to prove that the client signed the operation.

The result of a directory operation back to the client is either a "result" (either a confirmation that the requested action has been done or the information requested) or an "error" (when the operation cannot be resolved correctly, for example trying to read a non-existent entry will lead to an error). The results and errors may also be digitally signed, so that both parts of the operation (request and result) are signed. The client will request these signatures as a part of the operation.

In summary, all of the directory operation PDUs are digitally signed, so that the server can authenticate requests and the client can authenticate responses.

Distributed Operation

Signed operations also work with X.500 distributed operations. Where referrals are used, the security functionality is for client access as described in the previous section. This above diagram shows how signed operations work for chaining using X.500 Directory System Protocol (DSP). For DSP, there are two layers of signing:

• The inner layer, which provides communication between the Directory Client and the second server:
  • The signed DAP operation from the client to the first DSA is passed over DSP to the second DSA, which can use the signature to verify the directory client.
  • A DAP result or error signed by the second DSA is passed over DSP to the first DSA, which can pass it directly back to the client. This allows the directory client to verify the source of the error or result.
• The outer layer gives digital signatures of the operations between the two DSAs, and provides the security of signed operations for both the inner layer and the additional information in DSP used between the two DSAs.

The key benefit of signed operations with DSP is that it allows chaining to occur and provide strong authentication between the client and the chained to DSA, and in the reverse direction to authenticate the DSA providing the results back to the client.

Replication

Signed operations can also be used for directory replication using X.500 DISP (Directory Information Shadowing Protocol). As with client access, this works by providing a digital signature for each replication operation, for both total and incremental replication.

Benefits of Signed Operations

There are three basic security benefits of signed operations:

1. Authentication. It verifies the originator of the operation/result/error. In particular:
   • The server performing an operation can verify the digital signature of the requesting client (directly over DAP or indirectly over DSP) , which will be important as a part of the access control decision.
   • The client can verify the digital signature of the directory server providing results or errors (directly over DAP or indirectly via DSP chaining).
   • Authentication between directory servers for DSP (chaining) and DISP (replication) operations, results and errors.
2. Data Integrity. It verifies that data in the operations has not been corrupted or tampered with.
3. Non-repudiation. Operations and results can be stored as PDUs along with the associated digital signatures, to provide secure audit. This may be particularly important for update operations.

Usage and Configuration Requirements

The provision of directory signed operations has impact on the client and server implementation, so that products can be used in environments which always or sometimes make use of signed operations.

Directory Administration Clients

A secure environment is likely to make use of signed operations for all directory administration. A directory administrative client designed for use in a secure environment, often referred to as an Administrative Directory User Agent (ADUA), should sign all operations and request all results and errors to be signed. If this capability is turned off, this should be made clear to the user.

Signing operations will be an option provided by the ADUA, that may be required in some environments and whose presence may be enforced by the server. Technically, the signing could be transparent to the user, but security policy may make interaction desirable, for example:

• When the user makes a change to the directory, remind the user that the change is being digitally signed and ask for confirmation before doing the action. This could be integrated as part of a general confirmation process.
• The signature may be made by use of a smart card or soft key according to local configuration. Verification may require use of a pass phrase, which will be re-prompted for if the session has been idle for a period.

The signature status of results and errors being returned may be of interest to the administrator and it is desirable for the ADUA to display this information. Examples:

• A clear indication that a result or error is signed and the user clearly alerted in the event that a requested signature is not present.
• In the event of a signature failure, the user is clearly alerted to the failure and reasons for the failure (e.g., not able to check Certificate Revocation List). The user can then make a decision as to how to handle the verification error and any information returned by the directory.
• When an operation is signed by a directory server other than the one directly connected to by X.500 DAP, this is made clear to the administrator.

Directory Servers

In order to be useful in a range of environments, a directory server will need to have configuration options for using signed operations. In particular:

• Always require signed operations. This will be useful for some secure environments.
• Always require signed operations where updates are made. This will be useful, where it is desired to have the security of signed operations for update operations, but to allow reads and searches without signed operations, for example to support access from LDAP Clients (as signed operations are not available in LDAP).
• Always require signed operations from specific clients. This may be useful to require that all operations from an administrative client use signed operations.

In order to gain the audit benefit of signed operations, it is important to audit activity. By auditing each PDU and its signature, checks could be repeated. A simpler approach would be to (audit) log details of each verification performed, and to rely on the accuracy of the directory server’s audit logs.

Comparison with Alternative Approaches

This section considers some alternate approaches to providing data integrity and authentication. There are no other ways to provide the secure audit capabilities of signed operations, with a recorded digital signature for each operation.

Data Integrity

Data integrity may be provided by use of lower layer end to end services. The two appropriate standardize approaches are shown above:

1. Use of TLS (Transport Layer Security) security over TCP.
2. Use of IPsec as part of the IP (Internet Protocol) layer.

Both of these approaches provide good data confidentiality and data integrity services at the transport and network layer respectively, and are services that add security value in their own right. Both of these can be used in conjunction with X.500 protocols and LDAP to provide data confidentiality services, and are good approaches to achieve this.

They would be effective at protecting against some data integrity attacks that are protected against by signed operations, in particular attacks on data in transit. Because the integrity service is provided at a lower layer, they would not be effective against local attacks that came between the directory application and the lower layer security. The difficulty of such attacks would depend to a large extent on how tightly the directory application was integrated with the lower layers (e..g., in Isode’s M-Vault server and many other LDAP clients and servers, TLS is tightly integrated, which would make attacks relatively hard). It is clearly better to have an integrity mechanism that does not rely on implementation architecture and is closer to the data that is being protected.

Use of peer data confidentiality for integrity checking does not provide end to end checking when chained operations are used, and so a chaining DSA could modify the operation being chained.

Authentication

An alternative to using the strong authentication for each operation, is to use the per association strong authentication. This could be provided in a number of ways.

1. At the directory level, using X.500 DAP strong authentication.
2. By using lower layer strong authentication:
   • IPsec authentication, which may use X.509 based strong authentication.
   • TLS strong authentication. This can be referenced by LDAP, usually using the SASL EXTERNAL authentication method.

Strong peer authentication has independent benefits, and is required to be used in addition to signed operations, whenever signed operations are required. The considerations here are in respect of using peer strong authentication as an alternative to signed operations. The following disadvantages are noted:

1. Lower layer strong authentication approaches, particularly IPsec, have the same security concern for directory authentication as for using lower layer data integrity. There is a "gap" between the authentication and the application being authenticated. This is not desirable.
2. There is an implicit trust that the entity starting the application is the one that is invoking a specific operation.
3. There is a timing issue, as trust as the time of authentication may be different to trust at the time of the operation (e.g., a certificate being revoked). There could be security attacks based on long lived connections.
4. If authentication is only done for the initial bind, there is exposure to a class of man in the middle attacks that usurp an already authenticated connection.
5. The lack of signature for individual operations prevents per-operation secure audit.
6. Peer authentication does not give strong security for chained operations.

Conclusions & Recommendations

Directory signed operations provide additional security for directory services, and are desirable for deployments where security is important. They complement and add value to peer strong authentication services and to data confidentiality services.