INET Conferences

Conferences

INET


NDSS

Other Conferences

[INET'98] [ Up ][Next]

LDAPv3 Versus X.511 DAP Security: A Comparison and How to Sign LDAPv3 Operations

Vesna HASSLER <hassler@infosys.tuwien.ac.at>
Technical University of Vienna
Austria

Abstract

In this paper we give a comparative overview of the X.511 DAP (Directory Access Protocol) security features and the LDAPv3 (Lightweight Directory Access Protocol, Version 3) security features. We also propose a method to implement digital signature for LDAPv3 since this functionality has not been discussed in LDAPv3 documents so far.

Contents

Introduction

X.500 is a commonly used name for a series of joint ISO/IEC and ITU-T standards specifying a distributed directory service. It assumes the existence of an underlying OSI protocol stack. LDAPv3 is an Internet alternative for the standard X.511 access protocol (DAP). More information about X.500 and LDAPv3 can be found in [16]. Since its first version, LDAP has undergone significant changes, and many of them concern security. Originally it was planned to use LDAP only to access the X.500 directory via an LDAP gateway. In the meantime the LDAP functionality was extended, which enables LDAPv3 to be used for both the server model and the client read and update access protocol.

LDAPv3 has adopted some of the X.500 security concepts and some of the widely accepted Internet security solutions, like TLS. However, it is very difficult to obtain a clear picture of what security services are available in DAP and LDAPv3 and how they are implemented without having to study a huge pile of X.500 specifications and LDAPv3 documents. In this paper we give a comparative overview of the DAP and the LDAPv3 security features. Our analysis is based on the 1995 editions of the ISO directory standards [12, 13, 14] and the latest (as of February 1998) documents on LDAPv3 [1, 2, 3, 5, 6, 8, 18, 19].

Two security services that are required in many applications but have not been addressed by LDAPv3 in a satisfactory manner so far are integrity and nonrepudiation. According to the latest LDAPv3 security draft [6], integrity can be achieved within a secure association only. Nonrepudiation, and by this we mean digital signature of operations, is mentioned as an example for the usage of the LDAPv3 extended operation mechanism. We propose another solution that requires fewer changes in the protocol and can even be used to add other security services, like "pure" integrity. This solution is based on the LDAP controls which provide a way to specify extension information. They are sent as a part of an operation and apply to that operation only. In the proposed solution we follow the X.511 security model [13] as closely as possible.

The paper is organized in the following way. In the section DAP security we give an overview of the DAP security model. In the section Digital signature project we briefly present the project which gave the framework for this work. In the section LDAPv3 security we provide an overview of the current (as of February 1998) status of the proposals for LDAPv3 security. In the section How to sign LDAPv3 operations we propose a method for signing LDAPv3 operations based on LDAPv3 controls. With the section Summary and conclusions we conclude the paper and finally list the relevant References. All abbreviations used in the paper are explained in Abbreviations.

Digital Signature project

This work has emerged as part of the Digital Signature project coordinated by the Stuzza (Studiengesellschaft fuer Zusammenarbeit im Zahlungsverkehr) from Vienna, Austria. The aim of the project is to establish an infrastructure for applying smart-card-based digital signatures in banking applications. One of the requirements was to conform to all relevant international standards to ensure interoperability in case of later connecting to an international certification infrastructure. An important part of the infrastructure is a public directory in the form of an LDAP-server from which the X.509v3 certificates of the public signature keys can be retrieved. In order to provide for integrity, strong authenticity, and nonrepudiation of all relevant directory information, it was important to introduce the possibility of signing the information originating from the directory. In this way the user can be sure that he or she is talking to the right (i.e., trusted) directory when retrieving certificates and the certificate-related information.

DAP security

DAP is a protocol for read or update access to the X.500 directory, as shown in the following figure:

The client (DUA) is using DAP to access a directory server (DSA). The servers are interconnected and can interoperate to provide a global directory service to the user transparently. The servers are communicating using the protocol called DSP. The security services we are talking about in this paper can in general be applied to both protocols, i.e., DAP and DSP, but we will describe DAP in detail.

DAP, as well as LDAPv3, can be described by the following figure:

Bind request is a mandatory operation. Its arguments are protocol version, required authentication level, and the corresponding credentials. Depending on the type of access and the server requirements, the user may be authenticated using one of the following mechanisms:

  • No authentication
  • Simple authentication
  • Strong authentication
  • External authentication

Simple authentication is based on user passwords. In the simplest case a user password is sent in the clear, which is, of course, not recommended. The user password can be protected using a one-way function f1() in the following way:

Client sends to server: t1, r1, A, Protected1 = f1(t1, r1, A, passwordA)

t1 is a time stamp, and r1 a random number. They help detect replay attacks, i.e., ensure the freshness of messages. Time stamps should in general be used only if the client and the server clock are (at least logically) synchronized. A higher level of protection, i.e., lower chances of a successful birthday attack, can be achieved when using two one-way functions, f1() and f2(), in the following way:

Client sends to server: t1, t2, r1, r2, A, Protected2 = f2(t2, r2, Protected1)

To perform this type of authentication, there is a corresponding data structure in the protocol, called SimpleCredentials, which is an optional part of the bind request or the bind response message: 

SimpleCredentials       :=      SEQUENCE {
        name            [0]     DistinguishedName ,
        validity        [1]     SET {
          time1             [0]      UTCTime OPTIONAL,
          time2             [1]      UTCTime OPTIONAL,
          random1          [2]      BIT STRING OPTIONAL,
          random2          [3]      BIT STRING OPTIONAL} OPTIONAL,
        password        [2]     CHOICE {
          unprotected      OCTET STRING,
          protected        SIGNATURE{OCTET STRING}} OPTIONAL}}

For strong authentication, X.509 recommends three protocols based on the public-key cryptography: one-, two-, and three-way authentication. In the one-way authentication protocol, only one party is authenticated and the freshness is achieved by using time stamps and random numbers. Dx() denotes encryption with x's private key, i.e., x's digital signature. All necessary public keys for signature verification are obtained from X.509 certificates. Sending a digital signature means that both the cleartext message and the signature are sent:

Client sends to server: Dc(tc, rc, serverID)

In this way the client is authenticated. If the server has to be authenticated, too, an additional message is sent:

Server sends to client: Ds(ts, rs, clientID, rc)

Finally, if no time stamps are used, they are set to zero in the first two authentication messages, and an additional message is sent:

Client sends to server: Dc(rs, serverID)

The authentication messages can also be used for exchanging the session key information (key transport or key agreement). The key information has to be encrypted with the receiving party's public key. However, in the data structure for strong credentials there is no parameter that can be used to convey the key information. StrongCredentials are an optional part of the bind request or bind response message: 

StrongCredentials       :=      SET {
        certification-path      [0]     CertificationPath OPTIONAL,
        bind-token              [1]     Token,
        name                    [2]     DistinguishedName OPTIONAL}Token                   :=      SIGNED { SEQUENCE {
        algorithm               [0]     AlgorithmIdentifier,
        name                    [1]     DistinguishedName,
        time                    [2]     UTCTime,        
        random                  [3]     BIT STRING}}

The CertificationPath component contains the client's certificate. The name is the distinguished name of the client. An overview of the registered algorithm identifiers can be found in [11].

Authentication which is not resulting in a session key for the protection of the subsequent messages does not make much sense. However, this is not the case with either the simple authentication, because it is not its purpose, or the strong authentication, because the suggested procedures for exchanging the key information cannot be implemented in DAP in its present form. There is one more possibility for authentication: to use an external procedure to establish a secure session, as indicated in Figure 2.

Another useful security feature in DAP is that the server can be required to sign the result of an operation. The signing request can be sent as an optional part of the common arguments that is called SecurityParameters: 

SecurityParameters      :=      SET {
        certification-path      [0]     CertificationPath OPTIONAL,
        name                    [1]     DistinguishedName OPTIONAL,
        time                    [2]     UTCTime OPTIONAL,
        random                  [3]     BIT STRING OPTIONAL,
        target                  [4]     ProtectionRequest OPTIONAL}ProtectionRequest       :=      INTEGER { none(0), signed(1) }

The CertificationPath component contains the signer's certificate. The name is the distinguished name of the intended recipient. If the value of ProtectionRequest is set to signed, the server has to sign the response. An operation argument (part of a request) or operation result (part of a response) can be OPTIONALLY-SIGNED. time is the time stamp specifying the intended expiry time for the validity of signed requests. random is a random number and can be used in both signed request or signed response. The time stamp and the random number enable the detection of reply attacks, similarly to the simple and strong authentication.

The parameters required for the strong authentication are stored in an X.500 server as user attributes of the following types:

  • userCertificate: user (client or server) certificate
  • cACertificate: Certification Authority (CA) certificate
  • authorityRevocationList: Certificate Revocation List of user certificates
  • certificateRevocationList: Certificate Revocation List of CA certificates
  • crossCertificatePair: a pair of certificates with which two parties mutually certify each other

Their values are DER encoded ASN.1 structures described in [12].

The access control scheme specified in X.501 [14] enables defining many kinds of access control policies and is therefore very complex. The information about accessing directory information is specified as a data structure called ACIItem: 

ACIItem                 :=      SEQUENCE {
        identificationTag       DirectoryString {ub-tag},
        precedence              Precedence,
        authenticationLevel     AuthenticationLevel,
        itemOrUserFirst CHOICE {
                itemFirst       [0] SEQUENCE {
                        protectedItems  ProtectedItems,
                        itemPermissions SET OF ItemPermission},
                userFirst       [1] SEQUENCE {
                        userClasses     UserClasses,
                        userPermissions SET OF UserPermission}}}

precedence helps resolve conflicts if more than one ACIItem refers to the same piece of information, in such a way that the highest precedence value prevails over others. The access control is based on the access control matrix. The matrix is stored either column-wise as an access control list (itemFirst) or row-wise as a capability list (userFirst). In other words, all users which are allowed to gain specific access rights to protectedItems are listed in itemPermissions, and all items that may be accessed in a specified way by the users listed in userClasses are listed in userPermissions. Access control information is stored in operational attributes entryACI, prescriptiveACI, and subentryACI which are normally not visible to the client. They control access to a directory entry, a set of entries in a directory subtree, and to a set of subentries (holding the administrative information) in an administrative area, respectively. There is an additional attribute, accessControlScheme, whose value indicates the type of the access control scheme (such as Basic Access Control defined in X.501).

The directory access protocol is not concerned with the enforcement of the access control rules. However, the information the access control decision relies upon comes from the authentication process. The value of AuthenticationLevel specifies the required level of authentication: 

AuthenticationLevel     :=      CHOICE {
        basicLevels     SEQUENCE {
                level           ENUMERATED {none(0) simple(1), strong(2)},
                localQualifier  INTEGER OPTIONAL},
        other           EXTERNAL}

The value of level corresponds to the authentication procedures described earlier in the paper. localQualifier may be assigned to the client by the server according to the local policy. other is used for determining the authentication level if an external authentication mechanism is used.

LDAPv3 security

If you look at Figure 1 describing DAP, you will get a general idea about LDAPv3, too, except that the bind request in LDAPv3 is not mandatory and that currently there are no security parameters that can be sent along with the operations. LDAPv3 authentication mechanisms have not been standardized yet (as of February 1998). However, there is some work in progress [5, 6] which this overview is based on.

In the protocol [1] the bind request is defined as follows: 

BindRequest ::= [APPLICATION 0] SEQUENCE {
        version                 INTEGER (1 .. 127),
        name                    LDAPDN,
        authentication          AuthenticationChoice }AuthenticationChoice ::= CHOICE {
        simple                  [0] OCTET STRING,
                                 -- 1 and 2 reserved
        sasl                    [3] SaslCredentials }SaslCredentials ::= SEQUENCE {
        mechanism               LDAPString,
        credentials             OCTET STRING OPTIONAL }

LDAPv3 bind request is similar to the DAP bind request. However, there are some differences. LDAPv3 simple authentication is equivalent to DAP simple unprotected authentication. But, in the last version of the LDAPv3 authentication draft [6], it is recommended to use simple authentication only over a secure layer provided by TLS [10]. We describe how to use TLS with LDAPv3 later in this section.

Simple protected authentication can be used as the SASL CRAM-MD5 mechanism [7]. SASL [9] is an authentication framework for connection-based protocols. CRAM-MD5 can be described as follows:

Server sends challenge to client: <process-ID.clock@hostname>
Client sends response to server: MD5((password XOR opad), MD5((password XOR ipad), <process-ID.clock@hostname>))

In this way the client is authenticated if it knows the secret password. The roles of process-ID and clock are the same as of the random number and the time stamp in the X.509 authentication protocols, i.e., the protection against reply attacks. MD5 is a hash function, and its role is the same as of the one-way functions in DAP authentication. ipad and opad are padding parameters specified in [15].

Another simple authentication mechanism with password protection is proposed in [5]. Its name is "X.511-Protected" and it uses the same data structure as DAP SimpleCredentials with protected password (X.511 is the ITU-T number of the standard describing DAP). If CRAM-MD5 will be used for LDAPv3 password protection, X.511-Protected does not seem to be necessary.

The strong authentication mechanism based on DAP StrongCredentials was proposed in the same document [5] as an SASL mechanism called "X.511-Strong." The difference is in the absence of the client's distinguished name in the LDAPv3 version since X.511-Strong can read the client's name from the subject field in its certificate.

If an LDAPv3 server stores the DAP security attributes, they have to be stored as binary values because of the changes in the ASN.1 definition in various X.509 editions. An additional security attribute from the to-be-standardized LDAPv3 user schema is supportedSASLmechanisms [3].

A strong authentication mechanism that will most probably be mandatory for LDAPv3 is TLS. TLS 1.0 is based on SSLv3 and provides strong authentication, integrity, and privacy. To use TLS, the name of the SASL mechanism in the LDAP BindRequest has to be "EXTERNAL," and the credentials field has to be empty. The protocol scenario is the same as for external mechanisms in DAP, as shown in Figure 2. A TLS session must be established prior to sending a bind request. The client has to be authenticated by a strong mechanism, i.e., it has to have a certificate. The name under which the client binds to the server is the name from the client's certificate, so that the name in the bind request, if present, has to be identical to the name in the certificate. The TLS negotiation starts with an ExtendedRequest called "Start TLS." ExtendedRequest/Response mechanism is the inherent LDAPv3 extension mechanism which allows the addition of new operations to the protocol.

Now we can summarize the standardization status of the LDAPv3 security functionality: the client can

  • Bind as an anonymous user without authentication;
  • Use simple authentication to send a cleartext password over TLS;
  • Use the CRAM-MD5 SASL mechanism to send a protected password; or
  • Use the ExtendedRequest "Start TLS" to be strongly authenticated.

Access control is still not a mandatory part of an LDAPv3 server. There are some proprietary solutions, like for the Netscape Directory Server [17]. In [2] X.501 ACIItem is mentioned as one of the syntaxes defined for LDAP so far, but not as mandatory. The LDAPv3 requirements for an ACL-based access control are specified in [18]. It seems that the X.501 access control model could satisfy those requirements, but a serious evaluation has not been done so far. The last proposal (as of April 1998) for an LDAPv3 access control scheme can be found in [19].

How to sign LDAPv3 operations

Two security services that are often required but have not yet been addressed by LDAPv3 in a satisfactory manner are integrity and nonrepudiation. Integrity can be achieved only within a secure association, but without using strong cryptographic mechanisms. Nonrepudiation, and by this we mean digital signature of LDAPv3 operations (requests and responses), is mentioned as an example for the LDAPv3 extension mechanism (Extended Request/Response) that is to be specified in future RFCs or private implementations. We propose another solution which is more flexible since it allows the addition of other security mechanisms as well and which does not change the basic LDAP message structure. The proposal is based on the LDAP controls which provide the possibility to specify extension information. Controls can be sent as a part of an operation and apply only to that operation. In the proposed solution we follow the DAP security model as closely as possible.

If you look at DAP, you will notice that all operations except bind request and bind response have a common part which is called CommonArguments. An optional part of the common arguments is the SecurityParameters structure. We can now define LDAPSecurityParameters in a similar way: 

LDAPSecurityParameters  ::= SEQUENCE {
        controlType             LDAPOID -- to be assigned,
        criticality             BOOLEAN DEFAULT FALSE,
        controlValue            OCTET STRING}

The controlValue is an OCTET STRING, whose value is the BER encoding of the value of the following SEQUENCE: 

Parameters              ::= SEQUENCE {
        securityParameters     [0]     SecurityParameters,
        signature              [1]     AF.Signature OPTIONAL}SecurityParameters      ::= SET {
        certification-path     [0]     AF.CertificationPath OPTIONAL,
        name                   [1]     LDAPDN OPTIONAL,
        time                   [2]     generalizedTime OPTIONAL,
        random                 [3]     BIT STRING OPTIONAL,
        target                 [4]     ProtectionRequest OPTIONAL}ProtectionRequest       ::= INTEGER { none(0), signed(1) }

One important difference is that LDAPSecurityParameters include the actual signature. In X.511 all signed messages are "encapsulated" in the ASN.1 SIGNED MACRO. To strictly follow that approach, it would be necessary to define an ExtendedRequest/Response pair with the ASN.1 structure similar to the SIGNED MACRO.

The ASN.1 type AF.Signature is defined in [12], whereby AF stands for "Authentication Framework": 

AF.Signature            :=      SEQUENCE {
        algorithmIdentifier     AlgorithmIdentifier,
        encrypted               BIT STRING}

The value of encrypted is computed over the entire LDAPMessage with encrypted set to NULL (i.e., absent). The ASN.1 type AF.CertificationPath is also defined in [12]. In a typical case the control should not be critical, e.g., the server should be able to return a response even if it is not signed, and the client can decide how to evaluate it. An example scenario in which the client requires the search results to be signed by the server could be as follows:

  1. The client sends a SearchRequest message with the LDAPSecurityParameters containing time=tclient, random=r, and target set to "signed."
  2. To each part of the response (i.e., SearchResultEntry, SearchResultReference, and SearchResultDone) the server appends the LDAPSecurityParameters containing the certificate-path of the server, time=tserver, the random number r obtained from the client, and the signature.

If we allow the use of different types of mechanisms for the signature field, there is a straightforward way to provide for integrity based on MAC, such as described in [15].

Summary and conclusions

In this paper we gave an overview of the DAP and LDAPv3 security features. LDAPv3 takes DAP as a model to some extent. An important difference between the two protocols, from the security point of view, is that LDAPv3 has a well-defined external authentication procedure based on TLS which can provide integrity and privacy. Another difference is that LDAPv3 has no mandatory access control. Additionally, LDAPv3 does not provide the possibility of signing operations. However, there are at least two good reasons in favor of this feature, both of them relevant to both read-only and update access to the server:

  • Integrity -- Message integrity can be achieved with much less protocol overhead than when using TLS, i.e., without having to negotiate an underlying security layer.
  • Nonrepudiation -- This security service is not provided by any of the LDAPv3 security features [6], but can be required as a guarantee for the correctness of the server information.

In [1] the authors suggest extended operations to be used for adding signed operations. We proposed another solution based on the LDAPv3 controls which follows the DAP approach of common operation arguments which optionally include security parameters. Our approach also opens the possibility of providing other security mechanisms, such as "pure" MAC-based integrity. We hope that in the near future the LDAPv3 standardization efforts will go in a similar direction.

References

  1. M. Wahl, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3)," RFC 2251
  2. M. Wahl, A. Coulbeck, T. Howes, S. Kille, "Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions," RFC 2252
  3. M. Wahl, "A Summary of the X.500(96) User Schema for use with LDAPv3," RFC 2256
  4. D. Chadwick, Understanding X.500 -- The Directory, Chapman & Hall, 1994, available online
  5. M. Wahl, "X.500 Strong Authentication Mechanisms for LDAPv3," INTERNET-DRAFT draft-ietf-asid-ldapv3-strong-00.txt
  6. M. Wahl, H. Alvestrand, "Authentication Methods for LDAP," INTERNET-DRAFT draft-ietf-ldapext-authmeth-01.txt
  7. J. Klensin, P. Krumviede, "IMAP/POP AUTHorize Extension for Simple Challenge/Response," RFC 2195
  8. J. Hodges, RL Morgan, M. Wahl, "Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security," INTERNET-DRAFT draft-ietf-asid-ldapv3-tls-02.txt
  9. J. Myers, "Simple Authentication and Security Layer (SASL)," RFC 2222
  10. T. Diers, C. Allen, "The TLS Protocol Version 1.0," INTERNET-DRAFT draft-ietf-tls-protocol-05.txt
  11. German National Research Center for Information Technology GmbH, SECUDE-5.1 Hyper Link Documentation: Cryptographic algorithms
  12. International Organization for Standardization, Information technology -- Open Systems Interconnection -- The Directory: Authentication framework, ISO/IEC 9594-8 (also ITU-T X.509), 1995
  13. International Organization for Standardization, Information technology -- Open Systems Interconnection -- The Directory: Abstract service definition, ISO/IEC 9594-3 (also ITU-T X.511), 1995
  14. International Organization for Standardization, Information technology -- Open Systems Interconnection -- The Directory: Models, ISO/IEC 9594-2 (also ITU-T X.501), 1995
  15. H. Krawczyk, M. Bellare, R. Canetti, "HMAC: Keyed-Hashing for Message Authentication," RFC 2104
  16. Welcome to Critical Angle Inc.
  17. Netscape Directory Server
  18. E. Stokes, D. Byrne, B. Blakley, P. Behera, "Access Control Requirements for LDAP," INTERNET-DRAFT draft-ietf-ldapext-acl-reqts-00.txt
  19. B. Blakley, D. Byrne, E. Stokes, "Access Control Model for LDAP," INTERNET-DRAFT draft-ietf-ldapext-acl-model-00.txt

Acknowledgments

I wish to thank my colleagues from the Digital Signature project, Helmut Biely and Klaus Dillinger, for helpful discussions, and the Digital Signature project manager Manfred Holzbach from the Stuzza for giving me the opportunity to work on this project. I also wish to thank the members of the LDAP mailing list, especially Ellen Stokes, Thomas Salter, and Mark Wahl, for their helpful suggestions.

Abbreviations

LDAP: Lightweight Directory Access Protocol
DUA: Directory User Agent
DSA: Directory System Agent
DAP: Directory Access Protocol
DSP: Directory System Protocol
ACI: Access Control Information
ACL: Access Control List
TLS: Transport Level Security
SASL: Simple Authentication and Security Layer
CRAM-MD5: Challenge-Response Authentication Mechanism with MD5
DER: Distinguished Encoding Rules
MAC: Message Authentication Code

[INET'98] [ Up ][Next]