How LDAPv3 Is Extended

   

When the Internet Engineering Task Force (IETF) LDAP Working Group began work on LDAPv3, LDAPv2 work had recently been completed. LDAPv2 had a few shortcomings and missing features, some of which were incorporated into the LDAPv3 work. However, it was obvious that more feature enhancements would be required over time. Given that moving a protocol through the IETF standards process is a lengthy undertaking, an easier way of adding features to LDAP was needed. Instead of creating LDAPv4 and then LDAPv5, it would be better to develop a systematic method for extending LDAPv3 and add capabilities as requirements became clear.

The LDAP designers decided to provide three means for extending the protocol: controls, extended operations, and SASL mechanisms.

LDAP Controls

LDAP controls are extra pieces of information that accompany an existing LDAP operation and modify that operation in a useful way. For example, the Server-Side Sorting control modifies the behavior of the LDAP search operation. When the Server-Side Sorting control accompanies a search operation, the server sorts the search results before sending them to the client.

Each control contains an object identifier (OID) that uniquely identifies the type of control, a control-specific payload, and a flag that indicates the control's criticality. If a client sets the isCritical flag when sending the control to the server, the server must either perform the operation with the control taken into account, or return an unavailableCriticalExtension error and not process the operation at all. If the isCritical flag is not set by the client, the server is free to ignore the control if it cannot process it.

Multiple controls may be attached to a single operation. For example, the Virtual List View control is always used in conjunction with the Server-Side Sorting Request control.

LDAP Extended Operations

Sometimes new functionality needs to be added and no existing LDAP operation is similar to the required functionality. In such cases an LDAP extended operation may be defined to carry a completely new operation. An extended operation can carry any data. For example, Netscape has defined two LDAPv3 extended operations that mark the beginning and end of a bulk update of a directory server database. These extended operations allow a client to rapidly replace the contents of a portion of the directory server data over the network.

Each LDAP extended operation contains an OID that uniquely identifies the operation and an operation payload. The content of the payload is specific to each extended operation.

It is perfectly acceptable to attach controls to extended operations. Whether the control makes sense for the extended operation depends on the extended operation and the control.

SASL Authentication Mechanisms

One shortcoming of LDAPv2 is that it does not support a strong authentication protocol other than Kerberos v4, which was not widely deployed. The only widely available method for authenticating to an LDAPv2 server is to send a bind distinguished name (bind DN) and a password to the server, unencrypted. Clearly an authentication method that is not susceptible to eavesdropping was required. Rather than mandate a single strong authentication method for LDAPv3, the standards developers chose to incorporate an authentication framework called Simple Authentication and Security Layer ( SASL ) that allows multiple authentication protocols to exist. SASL is a method for adding authentication and, optionally , security to connection-oriented protocols such as LDAP. LDAP currently uses SASL to provide extensibility in authentication methods . The SASL framework is specified in RFC 2222.

A SASL mechanism describes the flow of information that needs to occur to support a particular authentication method. SASL mechanisms are defined for several authentication protocols, such as the Kerberos v5 authentication protocol and the DIGEST-MD5 authentication protocol. For LDAP to use a particular SASL mechanism, a standards document called a SASL profile was included in RFC 2829 that describes how SASL is used within LDAPv3.

When a client initiates a SASL bind operation, it indicates the particular type of SASL mechanism to use. Depending on the type of mechanism, multiple messages may need to flow back and forth between the client and server. For example, the DIGEST-MD5 SASL mechanism defined in RFC 2831 allows the server to verify that the client knows a password without requiring that the client send the password. Instead, the server constructs a challenge, and the client responds to the challenge in such a way that knowledge of the password is proven. This exchange requires four steps: the initial bind request, the server's challenge, the client's response to the challenge, and a response code from the server. SASL allows an arbitrary number of exchanges.

RFC 2829 describes in detail how two SASL mechanisms ”DIGEST-MD5 and EXTERNAL ”are used within LDAP. DIGEST-MD5 is an authentication method that does not transmit passwords in the clear over the network and is therefore less susceptible to eavesdropping attacks. The EXTERNAL SASL mechanism allows LDAP servers to reuse authentication credentials established by a lower-layer protocol such as Secure Sockets Layer (SSL) or Transport Layer Security (TLS). To ensure that LDAP authentication is secure from eavesdroppers, all LDAPv3-compliant servers that support password-based authentication are required to implement the DIGEST-MD5 SASL mechanism.

   


Understanding and Deploying LDAP Directory Services
Understanding and Deploying LDAP Directory Services (2nd Edition)
ISBN: 0672323168
EAN: 2147483647
Year: 2002
Pages: 242

flylib.com © 2008-2017.
If you may any questions please contact us: flylib@qtcs.net