X.500 Standard status
(Implementors' Guide)

X.509 Related activities

How to be involved

More Information

Tutorial section 1
X.500 General

Tutorial section 2
X.509 specific

Other PKI organizations

edit SideBar

Search

Protecting a directory

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.

X.500 specifies other protection feature than those defined by X.509 (see Access Control and Data Privacy Protection).

Levels of authentication

Authentication of partners
Figure 1 - Authentication of partners

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:

  • anonymous;
  • name only;
  • name and simple password;
  • name and protected password; and
  • strong authentication.

It is not necessary to have the same level of authentication in the Bind result as in the Bind request.

Anonymous and simple unprotected authentication

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.

Authentication with protected password

In order to prevent the password from being ear dropped during the transfer, the password may be protected. This is illustrated in figure 2.

Protected password
Figure 2 - Protected password

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:

  • A time value is generated (time1 in figure 2). This time value should specify the time after which the authentication should fail. This time should be "closely" after the current time.
  • A random number is generated. A new random number must be generated for each authentication attempt (random1 in figure 2). The value should be sufficient large to prevent the same number to be generated frequently.
  • The distinguished name of the sender, the time value, the random number and the password for the sender are combined and hashed to produce a message digest.
  • The resulting message digest is together with distinguished name, time1 and random1 included in the Bind request/result. The object identifier for the used hashing algorithm is also included as illustrated in figure 2.

The receiver of a Bind request/result will perform the authentication as follows:

  • If the value in time1 is less than the current time seen by the recipient, the authentication fails already here. Also, the time value should be different from previously recent received time values
  • If the value in the random1 is a value that has been received is equal to a value received in a recent Bind request/response, the authentication also fails.
  • If things are OK so far, the distinguished name, time1 and random1 included in the Bind request/result together with its own copy of the password are used to generate a message digest using the algorithm indicated.
  • If the generated message digest is equal to the message digest received in the Bind request/result, the authentication is positive, otherwise it fails.

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.

Strong authentication

TBP

Signing of directory operations

Signing in distributed environment

Figure x - Signing in a distributed environment

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:

  • If a DSA receives unknown components in a DAP request, it just retains that part unchanged and then DER encodes the known part.
  • The system receiving a request shall always check the signature based on the received data stream.

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.

Page Actions

Recent Changes

Group & Page

Back Links