X.500 Standard status
X.509 Related activities
How to be involved
Tutorial section 1
Tutorial section 2
X.509 at work
This section is only concerned with how to protect information in the directory utilising the capabilities specified by X.509. It considers authentication of users accessing a directory and the protection of the operations handled by a directory.
Authentication may performed in both direction between a DUA (or user) and a DSA and between DSAs. This authentication is performed as part of the Bind operation.
To handle different security requirements, X.500 offers different levels of authentication:
It is not necessary to have the same level of authentication in the Bind result as in the Bind request.
In an anonymous Bind request or result, neither the distinguished name of sender nor a password is included.
The next level of authentication is to supply only the distinguished name of the sender.
It is also possible to supply a distinguished name and a password in the clear. Each end of the communications partners must have shared knowledge of the password. How this knowledge is established and maintained is not currently specified by X.500. However, there is work in progress on Password Policy.
In order to prevent the password from being ear dropped during the transfer, the password may be protected. This is illustrated in figure 2.
As for password transferred in the clear, the communications partners must have shared knowledge of the password.
The procedure followed by the sender is as follows:
The receiver of a Bind request/result will perform the authentication as follows:
The sender of a Bind request or reply generates a random number and a time value. The time value should be the time after which the authentication should fail. The random value must be changed for each occurrence and the range of random numbers should be sufficient large. Following these rules, reply of a protected password sequence will be detected.
The above procedure allows the password to be protected during transfer and it prevents replay of the transmission sequence. If the attempted reply is done early, the random number will cause the authentication fail. If the reply is attempted sometime later, the random number may be accepted, but the authentication will fail due to the time value.
Signing of directory requests and results may be done when it is deemed necessary to ensure the integrity of the message and/or to ensure the identity of the sender.
The concept of signing is described in X.509 Overview. However, when it comes to signing directory operations, there are some additional considerations to be made.
Only DAP requests are discussed here. Similar considerations can be made for DAP results.
As illustrated in figure x, a DAP request may be chained from one DSA to another before arriving to the DSA or DSAs processing the request. If the DAP request is signed, the signature as generated by the requestor (DUA) is passed along with the request.
Figure x also illustrates that a DSA may add its own signature, which is then checked and removed by the next DSA.
It is a DSA processing the request that needs to check the signature of the DAP request. It is therefore important that the signature of the DAP request as issued by the DUA is not invalidated during chaining due any change in the DAP request. The DAP request shall not be changed by a chaining DSA. All information that has to be updated or added for chaining purposes must be included in the chaining argument. The exact encoding must also be maintained.
The latter has introduced some complication caused by a particular interpretation of the OSI seven layer model. It has been argued that Directory is at the Application Layer (Layer 7), while parsing and serialisation of the data is done at the Presentation Layer (Layer 6). In principle, the Presentation Layer should not be aware of the distributed nature of Directory and would completely parse and decode the message before passing the data on to the DSA implementation even when the DSA is only a chaining DSA. This interpretation may be reflected in some implementations. This means that the DAP request would be completely decoded and when chained on, then re-encoded.
X.500 specifies the Basic Encoding Rules (BER) for encoding data specified in the ASN.1 abstract syntax. BER allow for certain variation in the encoding. Two implementations encoding the same data according to the same abstract syntax may create slightly different bit-streams. If that is the case, the signature on the DAP request might be invalidated when the DAP request is decoded and later re-encoded. It was therefore felt necessary to define a variant of BER named Distinguished Encoding Rules (DER). This DER is defined in 6.1 of ITU-T Rec. X.509. When an encoding choice is possible, the DER specify the exact choice to be taken. By using DER for encoding it should be ensured that the message would not change during decoding and re-encoding.
However, it is only possible to completely decode and later re-encode a data stream if the abstract syntax is fully known. This is in conflict with the X.500 extension rules. A DUA may support some extensions not supported by one or more DSAs involved in the handling of the request. Such a DSA will not have fully knowledge of the abstract syntax and it is not always possible to deduce the abstract syntax from the received data stream. Accordingly, decoding and re-encoding in DER is not always possible.
From the third edition of X.500, the procedures were updated to specify:
It would have been more logical to specify that the original DAP request should be retained in its completed form and then forwarded unchanged. This is not what the X.500 specifies, but it is certainly an option an implementation may use to preserve processing power.
There is no good reason for a DSA to DER encode the chaining argument when a DSA signature is added. The next DSA will just verify the signature against the received message (DER encoding is more process consuming that BER encoding without the DER restriction).
It is necessary to DER encode the DAP request, as there is no assurance that a chaining DSA will not decode and re-encode the DAP request or part of it.