Note. The Standard calls the service the Directory Abstract Service, since the service interface is defined in abstract terms, using ASN.1. Real OSI implementations may provide a service to the user using programming language constructs, such as C procedures and data structures (or APIs).
The protocol is the mechanism that is used to relay a user's service request between OSI entities. In the case of the Directory, the protocol used by a DUA to relay a request to a DSA, is the directory access protocol (DAP). The DAP is built up from the parameters of the Directory service, as well as from those of two other OSI application services, namely the remote operations service (ROSE) [4.5] and the association control service (ACSE) [4.6]. The DUA can choose to operate in either synchronous mode or asynchronous mode. In synchronous mode, only one request at a time can be submitted to the Directory. The reply must arrive before the next request is submitted. In asynchronous mode, there can be many outstanding requests at any point in time.
Note. The Remote Operations Service provides a simple request-reply type of service. The user provides a request to the ROSE, and it packages the request correctly, sends it off, and gives the user the reply when it arrives. All Directory requests are carried via the ROSE.
Note. The ACSE provides the service that connects two remote applications together. The connection (or association) has to be made before any other messages can be passed. ACSE is therefore a necessary element of all OSI application protocols.
When a DSA relays a user's request to another DSA, it also needs a service and protocol. The parameters of the DSA service are the same as those of the Directory service, but in addition the chaining parameters have been added. The directory system protocol (DSP) is therefore similar to the DAP, but DSP requests also contain Chaining Arguments, and DSP results also contain Chaining Results (Chapter 9). One further difference, is the way in which the DSP uses the ROSE. With the DSP, either DSA may send requests to (invoke operations on) the other DSA. With the DAP, only the DUA may issue requests. (It would clearly be a nonsense for a DSA to try to retrieve directory information from a DUA!) Furthermore, DSAs can only operate in asynchronous mode.
The service, and hence the protocols, defined in the '88 edition of the Standard, have only been minimally affected by the '93 enhancements. This has been intentional, in that a design policy of the extension work was that '88 and '93 systems should be capable of interworking. Furthermore hooks were built into the '88 edition of the Standard so that the '93 enhancements could be easily slotted in later. (Examples of such hooks are the Security Error (Insufficient Access Rights) (§ 5.18.6) and the Service Control 'do not use copies of entries at all' (§ 5.4.1). It was known before the '88 Standard was finalised, that further work needed to be done, see Table 1.1.) Nevertheless, we did not get it 100% right in 1988, since it is always difficult to predict the future accurately. Consequently some 'rules for extensibility' had subsequently to be defined for the '93 protocols, that were also retrospectively applied to the '88 Standard via the defect mechanism. These rules are described at the end of this chapter (§ 5.19), and they should now ensure that any '96 or later enhancements to the Directory protocols, can be transparently handled by the earlier '88 and '93 implementations without them undergoing any further changes.
Because '88 implementations already exist, and will probably continue to exist for many years to come, the description of the service that is provided here differentiates between those features that are defined in the '88 edition of the Standard, and the additional features that are added by the '93 work.
The service consists of Bind and Unbind operations, four interrogation operations (two read-like operations and two search-like operations), an abandon operation, and four modification operations. Each will be described in turn. As we shall see later, human users are not always provided with the full functionality of this service, since a DUA implementation may choose not to make certain features available at its user interface (Fig. 4.1).
The Directory protocol version number currently only has one defined value - version 1 - and so all implementations talk the same language. The rules for extensibility ensure that '88 and '93 implementations both understand the same protocol and can interwork successfully (w/w 5.1). One final small point about the protocol version number. It can be omitted altogether from the Bind operation, in which case it is implied that version 1 is the desired Directory protocol i.e. this is the default.
The credentials of the initiator is a complex parameter. It can be set to either simple credentials or strong credentials, or can carry parameters not defined by the Standard, or can be omitted altogether. In the latter case, the caller would be unidentified and unauthenticated by the Bind operation. This is the mode most often used by the current (mostly academic) pilot projects, which allow public access to a significant amount of data held in the Directory. It is doubtful if many commercial organisations will allow unauthenticated access by external users once a significant amount of their data is held in X.500 conformant systems, although some data e.g. telephone numbers, may remain public.
The catch all hook which allows private institutions, such as the DoD or NATO, to define their own authentication parameters, is there to encourage greater use of X.500 by organisations which may have strict rules about security, and who do not want even their authentication mechanisms to be widely known.
As explained more fully in Chapter 7, simple credentials consist of a user name and password (or protected password), whilst strong credentials are based on digital signatures. Table 5.1 lists the parameters that make up simple credentials, and Table 5.2 those that make up strong credentials. In order to understand them more fully, you must first read Chapter 7.
Table 5.1 The parameters of simple credentials
| Parameter | ASN.1 Parameter Encoding | Mandatory/Optional |
| Sender's name | DistinguishedName | Mandatory |
| Timestamp 1 | UTCTime | Optional |
| Timestamp 2 | UTCTime | Optional |
| Random number 1 | BIT STRING | Optional |
| Random number 2 | BIT STRING | Optional |
| Password or Protected Password | OCTET STRING or
SIGNATURE {OCTET STRING} |
Optional |
Once the recipient has received the Bind operation, and successfully authenticated the initiator, the recipient sends a Bind Result reply to the initiator. The parameters of the Bind Result are identical to those of the Bind operation i.e. simple, strong, externally defined or no credentials. This allows the initiator to authenticate the recipient of the Bind operation. As explained in Chapter 7, a DSA will usually not send its password to the DUA, and so will either be unauthenticated or will use strong authentication.
If the authentication failed, a Security Error (either Inappropriate Authentication or Invalid Credentials - see § 5.18.6) can be returned to the initiator instead of a Bind Result.
If the recipient currently does not have sufficient resources with which to provide a service to the initiator, it may send a Service Error (Unavailable) -see § 5.18.3.
Table 5.2 The parameters of strong credentials
| Parameter | ASN.1 Parameter Encoding | Mandatory/Optional |
| Certification path from receiver to sender | CertificationPath | Optional |
| Strong authentication token | Digitally SIGNED SEQUENCE of:
Signature Algorithm Identifier DistinguishedName of Receiver UTCTime (a timestamp) BIT STRING (a random number) |
Mandatory |
| Requestor | The name of the sender | Optional |
Note. A non-user friendly interface such as DISH, provided with the Quipu implementation, does allow the user to Bind to different DSAs.
(This text is a bit dated now, since LDAP DUAs usually do allow the user to choose which directory server to Bind to - Ed.)
Applications using standardised DUA interfaces such as XDS [9.1] do have the Bind operation available to them via an equivalent procedure call, and the full set of Bind parameters is usually available to them.
Note XDS is a standardised interface between a DUA and any application that uses the Directory. It has been defined by the X.400 API Association of the USA and X/Open Ltd of the UK. It is far more complex than the LDAP API.
The Unbind Operation maps onto the Association Control service element A-RELEASE.
What effect received A- and A-P-ABORTs have on the service as perceived by the user, is again dependent on the DUA implementation. A DUA implementation could, for example, try to re-establish a terminated association automatically, thus shielding the user from its effects. Most interfaces will probably notify the user that a failure has occurred, for example, XDS passes communication failures to the application via a Communications-Error parameter.
Table 5.3 The Common Arguments
| Common Arguments | Described in |
| Service Controls | 5.4.1 |
| Security Parameters | 5.4.2 |
| Distinguished Name of Requester (DUA) | 7.8.1 |
| Operation Progress | 9.13.4 |
| Aliased RDNs | 9.13.6 |
| Extensions | 5.20 |
A few of these parameters are worthy of further explanation. If local scope is set (bit 2), then the operation should only be executed within some locally pre-defined area, for example, the home DSA or the set of DSAs in the local management domain. The precise meaning of local scope is not standardised, and so each administrator will have to configure their DSA(s) to respond appropriately. If a user's query cannot be satisfied within the local area, then an error will need to be returned. Unfortunately the Standard does not suggest which error should be returned in this instance, but Service Error (Out Of Scope), or Name Error (No Such Object) might be appropriate.
The interaction of the copy flags (bits 3 and 6) works as follows. '88 DSAs do not recognise bit 6, and so if bit 3 is not set, they may return any (partial or complete) copy to the user. In '93 DSAs, bit 6 is only meaningful if bit 3 is not set. If bit 3 is set then entry copies will never be used. If neither bit is set, the Directory will only use copied data if it can guarantee (subject to the weak consistency of shadowing - see § 6.1) that the answer returned from an entry copy is the same as that which would be returned from the master entry, were that to be used. The attribute complete flag used in shadowing (§ 6.3.1) tells a shadow DSA that it has a complete copy of an entry, and so in this case it can guarantee that the answer is the same. If a DSA cannot guarantee that its copy is complete, then it will always chain or refer the request to the master DSA. If a user is happy with an entry copy that may be incomplete, but which is locally accessible (and therefore quicker and cheaper to access), then bit 6 should always be set. I recommend that bit 6 should normally be set for human users browsing the Directory. This is because there are certain circumstances when a query can never be satisfied by an entry copy unless bit 6 is set. For example, when a shadow copy is made of the most commonly accessed attributes of a person, such as Email address and telephone number, but not of less useful ones, such as a facsimile photograph, then a request to Read All Attributes would always be chained (or referred) to the master entry by the '93 DSA holding the copy (unless bit 6 was set).
The maximum elapsed time is the time which all DSAs collectively have to process a user's request. It includes processing, queuing and communication time. Clearly in a distributed environment, a count in seconds cannot be meaningfully passed between DSAs, and so the home DSA converts this into a date and time (UTCTime) before chaining it to the next DSA (§ 9.13.10).
The maximum attribute size in octets is an approximate measure of the size of a stored attribute (its type and all its values) at a DSA. The measure is imprecise because different DSA implementations will store the same attribute in different ways, due to local storage techniques and syntaxes. Nevertheless, the control gives the user a useful mechanism for eliminating large attributes from returned results. If such attributes are excluded, then the user is told of this via the incompleteEntry boolean (§ 5.6.3) in the result.
Table 5.4 The Service Controls
| Parameter | ASN.1 Parameter Encoding | Default |
| Prefer Chaining rather than Referrals | Bit 0 of BIT STRING | No preference for either |
| Chaining is prohibited | Bit 1 of BIT STRING | Chaining is OK |
| Operation should only be performed locally | Bit 2 of BIT STRING | Operation can be performed globally |
| Do not use copies of entries at all | Bit 3 of BIT STRING | (Complete) copies of entries are OK |
| Do not dereference aliases during name resolution | Bit 4 of BIT STRING | Aliases can be dereferenced |
| *Access Subentries
(List and Search only) |
Bit 5 of BIT STRING | Subentries are inaccessible in List and Search operations |
| *Partial copies of entries will do | Bit 6 of BIT STRING | Only complete copies of entries are OK |
| Operation priority | INTEGER (0=low, 1=medium, 2=high) | Medium Priority |
| Maximum elapsed time in seconds | INTEGER | Infinity |
| Maximum number of entries to be returned in a List or Search | INTEGER | Infinity |
| Only return referrals to | INTEGER (0=the local domain, 1=this country) | Referrals to anywhere |
| *Maximum attribute size in octets | INTEGER | Infinity |
If the user asks for a level of service that is different from the one normally provided by the Directory (i.e. the service that would be provided if the service controls had not been set), then the Directory will flag a problem to the user in the result. For example, if the user said do not dereference aliases and an alias was encountered, then the Directory would return the error Name Error (Alias Dereferencing Problem); or if the user set the size limit below the actual number of entries that were capable of being returned, then the Directory would signal a Partial Result (Size Limit) and only return an arbitrary selection of entries up to the number requested. If however the user asks for a level of service that is equalled or surpassed by Directory, e.g. the user sets a time limit of 10 seconds, and the complete response is generated in 5 seconds, then no problem will be flagged.
Table 5.5 Security Parameters
| Parameter | ASN.1 Parameter Encoding |
| Certification path from the recipient to the sender | CertificationPath |
| The name of the recipient | DistinguishedName |
| A Timestamp | UTCTime |
| A Random number | BIT STRING |
| Protection Request | INTEGER(0=none 1=signed) |
When security parameters are present in Chaining Arguments, then protection request is set by the chaining DSA, and it indicates whether or not the chained result should be signed. Signatures on chained results are always removed by the receiving DSA as explained in § 7.6, and these are independent of the signature on the operation result (which is embedded in the chained result).
Protection request cannot be set in the security parameters of either Chaining Results or Common Results.
The standardised API, XDS, allows the calling application to have full control of all the Common Arguments (except that the setting of security parameters is not standardised).
Table 5.6 The parameters of Common Results
| Common Results | Described in |
| Security Parameters | 5.4.2 |
| Distinguished Name of the Result Originator | 7.8.2 |
| Alias Dereferenced Flag | 5.5 |
I have used the term purported name instead of distinguished name for the name of the entry, since the name presented by the user may not actually be the distinguished name of an entry. The purported name, which is syntactically the same as a distinguished name, is the user's best guess for the name of the entry, but it may or may not name an actual entry in the DIT. If it does name an entry in the DIT, then it truly was a distinguished name, and the user will receive a result. Alternatively, the purported name may reference an entry via one of its alias names, in which case the user will be informed of this in the result (via the alias dereferenced flag of Common Results).
Table 5.7 The parameters of the Read operation
| Read Arguments | Described in |
| Purported Name of an Entry | 5.6 |
| Entry Information Selection | 5.6.1 |
| *Tell Me My Modify Rights | 5.6 |
| Common Arguments | 5.4 |
Similarly, the purported name may reference an entry via an alias of one of the superiors of the entry. Finally, the purported name may not reference any entry in the DIT. In this case the user would be sent an error diagnostic, most probably Name Error (No Such Object), instead of a result.
The parameter 'entry information selection' is a complex parameter which precisely describes the information that the user wants to retrieve from the entry. It is described in the next section.
'Tell me my modify rights' is a boolean, which if set to True by the user, will return the complete set of modification access rights that the user has to the particular entry. This new feature was added as a result of the access control work, which from reading Chapter 8, you will gather is quite complex. This boolean should allow users to simply find out what modification rights they possess to an entry.
Section 5.6.4 gives an example of a Read request and the returned result.
An '88 DUA implementation can select All User Attributes (w/w 5.6), which will return all the attributes held by an '88 DSA, or all those attributes held by a '93 DSA which are classified as user attributes. Remember that this is all the attributes defined in the '88 Standard, plus collective ones defined in the '93 Standard. So an '88 DUA will be able to retrieve more (user) attributes from a '93 DSA, than from an '88 DSA.
Table 5.8 The parameters of Entry Information Selection
| Parameter | Allowed Values | Default |
| Selected Attributes | either All User Attributes or Specifically Named Attributes | All User Attributes |
| Selected Information | either Attribute Types Only or Attribute Types and Values | Attribute Types and Values |
| *Selected Extra Attributes | either All Operational Attributes or Specifically Named Attributes | None |
Alternatively, the '88 DUA can individually specify which attributes are to be returned. If an empty set is specified by the user, then no attributes will be returned in the response. The specification can be for any type of attribute: user, collective or operational, but of course, the '88 DUA cannot tell the difference. When accessing a '93 DSA, increased functionality is gained by the '88 DUA, in that it can access operational attributes held by the '93 DSA. A '93 DUA has the same capability as the '88 DUA described above, but in addition, it can select extra attributes. An '88 DUA cannot select extra attributes, as it is not aware that this parameter exists. If an '88 DSA receives a request for extra attributes, it will ignore this unknown parameter (§ 5.19). It will only return those attributes already selected by the first parameter.
If the '93 DUA's request is for all operational attributes, then a '93 DSA will return all the operational attributes stored in the entry. This is in addition to the attributes already selected via selected attributes. An '88 DUA can only retrieve all the operational attributes held in a '93 entry, by specifically naming them all (you will agree that this is very tedious!).
Alternatively, the '93 DUA can specifically list the set of extra attributes to be returned. So for example, a '93 DUA can simultaneously request all user attributes and a selection of operational attributes. This latter task can only be achieved by an '88 DUA if it makes two Read requests to the Directory, one for all user attributes and one for specifically named operational attributes. If the '93 user lists two sets of attributes, using the first and third parameters, and mistakenly puts the same attribute in both lists, then the DSA may return it twice. In order to understand why the user may specify two lists of attributes, see w/w 5.7.
One final point about the attributes which will be returned. With the introduction of attribute hierarchies (§ 2.10), if the user specifically names an attribute super-type, then the super-type and all its sub-types will be returned by '93 DSAs, and the sub-types will be specifically identified. This might be confusing to an '88 DUA, which may receive more attributes from a '93 DSA than it actually asked for!
Having determined the attributes of interest, the user finally specifies whether the attribute types only (i.e. just the object identifiers) or the types and their values, are to be returned.
The returned modify rights requested by the user, lists the modify permissions that the user has for each attribute type and each attribute value stored in the entry, and also for those of the entry as a whole. See Chapter 8 for a full description of these permissions.
Table 5.9 The parameters of the Read Result
| Read Result | Described in |
| The Entry Information requested | 5.6.3 |
| *The Modify Rights requested | 5.6.2 |
| Common Results | 5.5 |
'88 DSAs always return the distinguished name of the entry being read. '93 DSAs only return the distinguished name of the entry if the user has permission (grantReturnDN - see Chapter 8) to know it. If the user does not have permission, then the Directory will, in the case of a Read operation or the base object of a Search operation, return the purported name provided by the user on the request; or in the case of other entries selected by a Search operation, either return the name of an alias of the selected entry or omit the entry from the result.
Table 5.10 The parameters of Entry Information
| Parameter | ASN.1 Parameter Encoding |
| The name of the entry | Distinguished Name |
| Flags if the information was retrieved from the entry (rather than a copy) | BOOLEAN DEFAULT TRUE |
| The requested information | SET OF either Attribute Types or Attribute Types and Values |
| *Flags if the entry information is incomplete | BOOLEAN DEFAULT FALSE |
The requested information of attribute types, or types and values, is returned in response to that which the user selected. A DSA will return as much information as is possible, subject to access controls and limits such as time and size. DSA implementations should allow administrators to set parameters which limit the amount of information that the DSA is willing to return to users, as well as to control the amount of processing time that the DSA will spend on behalf of users.
If a DSA cannot return anything that the user asked for, then in response to a Read operation, it will return the error Attribute Error (No Such Attribute Or Value), whereas in response to a Search operation it will return an empty set of information. '93 DSAs have the additional capability of flagging that the returned information is incomplete in some way. This can be used in situations where an attribute exceeds the requested attribute size (§ 5.4.1), or where a user does not have access rights to everything (Chapter 8).
If the information was retrieved from a shadow or cached copy of the entry, then the from entry boolean is set to False.
Fig. 5.1 An example of a Read Request.
Supposing that all of this is achieved, then Fig. 5.1 shows the parameters that would be sent to the Directory in the Read operation. It also shows the parameters of the Read response that would be sent back to the DUA. If a parameter is not shown in the figure, then it means that the standardised default values are to be assumed by the recipient e.g. strong authentication is not being used in this example. Note that the syntax used in the example request and response messages is only a simple approximation of the ASN.1 values.
The Compare operation is really only of use in checking the value of attributes, such as passwords, that their owners do not wish the Directory to return to anyone. A fuller description of its role in this respect is described in Chapter 7.
The parameters of the Compare operation are shown in Table 5.11.
Table 5.11 The parameters of the Compare Argument
| Compare Arguments | Described in |
| The Purported Name of an Entry | 5.6 |
| The Purported Attribute Value | 5.7 |
| Common Arguments | 5.4 |
Fig. 5.2 An example of a Compare Request.
Table 5.12 The parameters of the Compare Result
| Compare Result | ASN.1 Parameter Encoding |
| The distinguished name of the entry | DistinguishedName OPTIONAL |
| The matched flag - indicates the result of the comparison | BOOLEAN |
| Flags if the information was retrieved from the entry | BOOLEAN DEFAULT TRUE |
| *The subtype used in the comparison | AttributeType OPTIONAL |
| Common Results | see § 5.5 |
The matched flag is set to True if the entry does contain the purported attribute value presented by the user, and to False if it does not. '93 DSAs will also return False, if the user does not have permission to compare against the actual attribute value (Chapter 8).
Because '93 DSAs support attribute hierarchies, they are also allowed to perform the comparison against sub-types of the presented attribute, which are held in the entry. If a match was obtained against a value of a sub-type rather than the presented type, then the matched flag would be set to True, but in addition, the actual sub-type of the attribute used in the comparison would be returned to the user. For example, if I asked the Directory if an entry held a password attribute with value FRED, a 93 DSA might reply Yes, but it is a login password attribute (assuming login password is an attribute sub-type of password).
'93 DSAs also support collective attributes. Because collective attributes appear to be in an entry just like the other user attributes, they can be used in the Compare operation just like the other attributes.
Finally, if the comparison was executed in a shadow or cached copy of the entry, then the from entry boolean is set to False.
